Asesoramiento/razones de estilo de codificación para colocar espacios en instrucciones de control con C++

Question

Teniendo en cuenta los dos estilos de codificación siguientes, especifique una razón (algunos pros/contra) de por qué uno sería posiblemente preferible al escribir Código C++

(favor hacer no respuesta con "no es importante", "sólo se adhieren a uno"; etc. La pregunta es específicamente acerca de los posibles pro/contras (si lo hay) de los dos .. espaciar estilos por debajo Gracias )

// VARIANT A (NO space after control keyword/space before curly brace) 
if(condition) { 
    // ... 
} 
else if(c2) { 
    // ... 
} 
else { 
    // ... 
} 

for(int i=0; i<e; ++i) { 
    // ... 
} 

... 

// vs. VARIANT B (space after control keyword/NO space before curly brace) 

if (condition){ 
    // ... 
} 
else if (c2){ 
    // ... 
} 
else{ 
    // ... 
} 

for (int i=0; i<e; ++i){ 
    // ... 
} 

... 

Nota: Aparte de las cuestiones de gusto, me pregunto porque veo ambos estilos en nuestra base de código y lo intenta conseguir algunos argumentos para el que se va a privilegiado.

Answer 1

recientemente me fijo un poco de código en una sola línea, si fue modificado y alguien se olvidó de añadir un poco tirantes.

Al leer el código, me pareció, que el estilo ...condition){ es difícil de leer que el estilo ...condition) { porque el cierre y la apertura ){ son más fáciles de ver cuando están separadas por un espacio. (Cuando se utiliza Courier New en VS2005 - puede ser diferente con diferentes tipos de letra, supongo.)

también yo diría que con if( la separación es bastante claro y sin ningún espacio en blanco añadido, sobre todo porque en un editor moderno del if muy probablemente ser color diferente de (, pero { es probable que tenga el mismo color.

Aquí hay un pequeño ejemplo:

if (pPointer && pPointer->condition(foobar)){ 
    SendEvent(success_foobar); 
    Log(success_foobar); 
} 
if (pPointer && pPointer->condition(foo)) 
    SendEvent(success_foo); 
    Log(success_foo); 
if (pPointer && pPointer->condition(bar)){ 
    SendEvent(success_bar); 
    Log(success_bar); 
} 

vs.este (que creo que hace que el aparato ortopédico falta un poco más claro):

if(pPointer && pPointer->condition(foobar)) { 
    SendEvent(success_foobar); 
    Log(success_foobar); 
} 
if(pPointer && pPointer->condition(foo)) 
    SendEvent(success_foo); 
    Log(success_foo); 
if(pPointer && pPointer->condition(bar)) { 
    SendEvent(success_bar); 
    Log(success_bar); 
} 

Para resumir, se puede argumentar que la distinción visual de los editores modernos es mucho más grande hoy en día, por ejemplo, if y (, por lo que estos no necesitan espacios, mientras que ( y { a menudo tienen el mismo color y no son visualmente distintos, por lo que un espacio puede estar en orden.

Answer 2

Normalmente coloco espacios entre todos los operadores. Simplemente es más rápido analizar sintácticamente. Tal vez si tu vista es mejor que la mía.

Answer 3

Dado que este es probablemente mucho sobre el hábito y el gusto, podría ser difícil conseguir argumentos concretos a favor o en contra, pero aquí es lo que pienso:

Tanto funciona razonablemente bien, pero ¿cómo se vería tener espacios en llamadas de función? de esta manera:

len = strlen (somePtr); 

Eso es al menos un espacio demasiados en mi opinión.

Tener espacios en ese ejemplo hace que las cosas parezcan más una declaración de control que una llamada a función, y creo que es útil hacer if/else/while/para destacar un poco.

Pero me doy cuenta de que esta es una visión bastante subjetiva. :)

Answer 4

Mucha gente se obsesiona mucho sobre dónde colocar los espacios, llaves, paréntesis, corchetes, punto y coma, y ​​al mismo tiempo, olvidando que lo más importante sobre el código fuente es que necesita para ser entendido por otro ser humano.

Al compilador no le importa el formateo.

Después de muchos años en la profesión de programación, he llegado a utilizar esta una regla simple:

¿Es fácil de leer y entender lo que el código está haciendo?

No importa cómo formatee el código, si no se cumple la condición anterior, el código es de mala calidad.

Tengo una preferencia personal para formatear, y no diré qué es aquí, ya que realmente no importa de qué se trata.

Me resulta útil tener diferentes programadores de código en diferentes estilos.

Por supuesto, existe una excepción a esta regla: los ejemplos de documentación y tutoriales siempre deben ser coherentes; es necesario que el lector siga los elementos importantes que se muestran y no se desvíe por el formateo.

Answer 5

De su pregunta, parece como si fuera consciente de que mucha gente le dirá que no importa. Dado que ya sabe esto, ¿por qué insiste en que debe haber alguna razón objetiva para usar un estilo sobre el otro?

Si el espaciado es realmente el problema más importante en su código base, su equipo debe ser el mejor equipo en la historia de la programación. Si no, debe preocuparse más por expresar las ideas con claridad y si el software cumple su propósito.

Answer 6

Con el advenimiento de los IDE modernos y el formato de código automático, esto realmente no es ni aquí ni allá. Y no aconsejaría el cambio total de espacios (o cualquier otro cambio de formato) para el código existente en un vcs. Los desarrolladores tenderán a apegarse al formato con el que están familiarizados y siempre que el código transmita bien la intención, cuando se inserta un espacio en particular es totalmente redundante en mi humilde opinión. Lo que es muy probable que hacer es molestar a la gente que está acostumbrada a hacerlo de una manera mediante la aplicación de algo que se ideó en ellos ...

centrarse en los problemas de programación, no el formato ...

Answer 7

personalmente prefiera este estilo:

if(condition) 
    oneLiner(); 
else if(complicatedCondition(someVar, otherVar)) 
{ 
    more(); 
    than(); 
    oneLiner(); 
} 
else if(otherCondition) // I would prefer to put this in one if with '&&' between conditions... 
{ 
    if(nestedCondition) 
     oneLiner(); 
} 
else 
{ 
    // ... 
} 

for(int i = 0; i<e; ++i) 
{ 
    // ... even for one-liner loops which occasionally might happen 
} 

¿Por qué?

1. Los apoyos están alineados
2. No hay espacio desperdiciado en Oneliner if s.
3. Los bucles se observan claramente con llaves (siempre)
4. Solo el nivel exterior tiene espacios antes o después de los paréntesis. Sigue siendo un desastre si hay más de tres niveles de llamadas de función involucradas, como some(function(calling(another(function())))
5. un único espacio después de un punto y coma y una coma para una fácil ubicación de estos tipos de delimitadores.
6. Anidados if s necesitan refuerzos a su alrededor.

Esto es por supuesto puramente personal, y cualquier comentario sobre mi estilo será ignorado flagrantemente ;-)