coding-style - standard - google code styles

Uso obligatorio de tirantes

Question

Como parte de un documento de estándares de código que escribí hace un tiempo atrás, aplico "siempre se deben usar llaves para los bucles y / o bloques de códigos condicionales, incluso (especialmente) si son solo una línea".

Ejemplo:

// this is wrong
if (foo) 
    //bar
else 
    //baz
while (stuff)
    //things

// This is right.
if (foo) {
    // bar
} else {
    // baz
}
while (things) {
    // stuff
}

Cuando no preparas una sola línea y luego alguien la comenta, estás en problemas. Si no se ajusta a una sola línea y la sangría no se muestra igual en la máquina de otra persona ... está en problemas.

Entonces, pregunte: ¿hay buenas razones por las que esto sería un estándar erróneo o irrazonable? Ha habido cierta discusión al respecto, pero nadie puede ofrecerme un contraargumento mejor que "se siente feo".

Answer 1

Aplico esto a un punto, con pequeñas excepciones para las sentencias que evalúan devolver o continuar un ciclo.

Por lo tanto, esto es correcto por mi norma:

if(true) continue;

Como es esto

if(true) return;

Pero la regla es que es un retorno o continuar, y todo está en la misma línea. De lo contrario, se prepara para todo.

El razonamiento es tanto para tener una forma estándar de hacerlo como para evitar el problema de los comentarios que mencionó.

Answer 2

Aquí están las reglas no escritas (hasta ahora supongo) por las que paso. Creo que proporciona legibilidad sin sacrificar la corrección. Se basa en la creencia de que la forma corta en algunos casos es más legible que la forma larga.

• Siempre use llaves si algún bloque de la instrucción if/else if/else tiene más de una línea. Los comentarios cuentan, lo que significa que un comentario en cualquier parte del condicional significa que todas las secciones del condicional reciben llaves.
• Opcionalmente use llaves cuando todos los bloques de la declaración sean exactamente una línea.
• Nunca coloque la declaración condicional en la misma línea que la condición. La línea después de la sentencia if siempre se ejecuta condicionalmente.

• Si la declaración condicional realiza la acción necesaria, el formulario será:

  for (init; term; totalCount++)
  {
      // Intentionally left blank
  }

No es necesario estandarizar esto de manera verbosa, cuando solo puede decir lo siguiente:

Nunca deje tirantes a expensas de la legibilidad. En caso de duda, optar por utilizar llaves.

Answer 3

Creo que lo importante de los frenillos es que expresan definitivamente la intención del programador. No deberías tener que inferir intención de sangría.

Dicho esto, me gustan los retornos de una sola línea y continúa sugerido por Gus. La intención es obvia, y es más limpia y fácil de leer.

Answer 4

El mejor argumento contrario que puedo ofrecer es que las líneas adicionales ocupadas por el espacio reducen la cantidad de código que puede ver al mismo tiempo, y la cantidad de código que puede ver al mismo tiempo es un factor importante en la facilidad con que es para detectar errores. Estoy de acuerdo con las razones que me has dado para incluir llaves, pero en muchos años de C ++ solo puedo pensar en una ocasión en la que cometí un error como resultado y fue en un lugar donde no tenía una buena razón para saltarme las llaves. de todas formas. Desafortunadamente, no podría decirte si ver esas líneas extra de código alguna vez ayudó en la práctica o no.

Quizás estoy más predispuesto porque me gusta la simetría de las llaves que coinciden en el mismo nivel de sangrado (y la agrupación implícita de las declaraciones contenidas como un bloque de ejecución), lo que significa que agregar llaves todo el tiempo agrega muchas líneas a la proyecto.

Answer 5

En la actualidad, trabajo con un equipo que vive de acuerdo con este estándar y, aunque me resisto a él, cumplo por el bien de la uniformidad.

Objeto por el mismo motivo por el que me opongo a los equipos que prohíben el uso de excepciones o plantillas o macros: Si elige usar un idioma, use el idioma completo. Si las llaves son opcionales en C y C ++ y en Java, su mandato por convención muestra cierto temor por el lenguaje en sí.

Entiendo los peligros descritos en otras respuestas aquí, y comprendo el anhelo de uniformidad, pero no simpatizo con el subconjunto de idiomas a menos que exista alguna razón técnica estricta, como el único compilador para algún entorno que no tenga cabida para las plantillas o la interacción con el código C excluyendo el amplio uso de excepciones.

Gran parte de mi día consiste en revisar los cambios enviados por los programadores junior, y los problemas comunes que surgen no tienen nada que ver con la colocación de corsé o las declaraciones que terminan en el lugar equivocado. El peligro es exagerado. Prefiero pasar mi tiempo enfocándome en más problemas materiales que en buscar violaciones de lo que el compilador aceptaría felizmente.

Answer 6

Estoy de pie en el suelo que los frenos deben coincidir de acuerdo con la muesca.

// This is right.
if (foo) 
{
    // bar
}
else 
{
    // baz
}

while (things) 
{
    // stuff
}

En cuanto a sus dos ejemplos, consideraría que el suyo es un poco menos legible, ya que encontrar los paréntesis de cierre coincidentes puede ser difícil, pero más legible en los casos en que la sangría es incorrecta, al tiempo que permite que la lógica se inserte con mayor facilidad. No es una gran diferencia.

Incluso si la sangría es incorrecta, la sentencia if ejecutará el siguiente comando, independientemente de si está en la siguiente línea o no. La única razón para no poner ambos comandos en la misma línea es para el soporte del depurador.

Answer 7

Guau. ¿Nadie es consciente del problema de la otra cosa que cuelga ? Esta es esencialmente la razón para siempre usar llaves.

En pocas palabras, puede tener una lógica desagradable y ambigua con las instrucciones else, especialmente cuando están anidadas. Diferentes compiladores resuelven la ambigüedad a su manera. Si no sabes lo que estás haciendo, puede ser un gran problema dejar las llaves.

La estética y la legibilidad no tienen nada que ver.

Answer 8

La única gran ventaja que veo es que es más fácil agregar más sentencias a los condicionales y los bucles que están preparados, y no se necesitan muchas pulsaciones adicionales para crear las llaves al comienzo.

Answer 9

La única manera de que un grupo de programadores pueda seguir bien los estándares de codificación es mantener el número de reglas al mínimo.

Equilibre el beneficio con el costo (cada regla adicional confunde y confunde a los programadores, y después de un cierto umbral, en realidad reduce la posibilidad de que los programadores sigan cualquiera de las reglas)

Entonces, para hacer un estándar de codificación:

• Asegúrese de que puede justificar cada regla con evidencia clara de que es mejor que las alternativas.

• Mire las alternativas a la regla, ¿es realmente necesaria? Si todos sus programadores usan bien los espacios en blanco (líneas en blanco y sangría), una instrucción if es muy fácil de leer, y no hay manera de que incluso un programador novato pueda confundir una declaración dentro de un "if" con una declaración que sea independiente. Si está recibiendo muchos errores relacionados con el alcance de if, la causa principal es que probablemente tenga un estilo pobre de huella dactilar / sangría que hace que el código sea innecesariamente difícil de leer.

• Priorice sus reglas por su efecto medible en la calidad del código. ¿Cuántos errores se pueden evitar mediante la aplicación de una regla? (Por ejemplo, "verificar siempre que no haya nulos", "validar siempre los parámetros con una declaración", "escribir siempre una prueba unitaria" en lugar de "siempre agregar algunas llaves, incluso si no son necesarias") . Las reglas anteriores le ahorrarán miles de errores al año. La regla del corsé podría salvarte una. Tal vez.

• Mantenga las reglas más efectivas y deseche la paja. Chaff es, como mínimo, cualquier regla que le costará más implementar que los errores que pueden ocurrir al ignorar la regla. Pero probablemente si tiene más de unas 30 reglas clave, sus programadores ignorarán muchas de ellas y sus buenas intenciones serán como polvo.

• Encienda a cualquier programador que comente bits aleatorios de código sin leerlo :-)

PD: Mi postura respecto a los refuerzos es: si la declaración "if" o el contenido de los mismos son una sola línea, entonces puede omitir los refuerzos. Eso significa que si tiene un si contiene un comentario de una línea y una sola línea de código, el contenido toma dos líneas y, por lo tanto, se requieren llaves. Si la condición if abarca dos líneas (incluso si el contenido es una sola línea), entonces necesita llaves. Esto significa que solo se omiten llaves en casos triviales, simples y fáciles de leer, donde los errores nunca se cometen en la práctica. (Cuando una declaración está vacía, no uso llaves, pero siempre hago un comentario que indica claramente que está vacío, e intencionalmente. Pero eso limita con un tema diferente: ser explícito en el código para que los lectores sepan que usted quiso decir un alcance para estar vacío en lugar de que el teléfono sonara y se olvidó de terminar el código)

Answer 10

Me resulta difícil discutir los estándares de codificación que reducen los errores y hacen que el código sea más legible. Al principio puede parecerle desagradable a algunas personas, pero creo que es una regla perfectamente válida para implementar.

Answer 11

Mi regla personal es si es un ''si'' muy corto, luego colóquelo en una línea:

if(!something) doSomethingElse();

Por lo general, uso esto solo cuando hay un montón de ifs como este en sucesión.

if(something == a) doSomething(a);
if(something == b) doSomething(b);
if(something == b) doSomething(c);

Sin embargo, esa situación no se presenta con mucha frecuencia, de lo contrario, siempre uso frenillos.

Answer 12

Muchos idiomas tienen una sintaxis para una línea como esta (estoy pensando en perl en particular) para lidiar con esa "fealdad". Así que algo como:

if (foo)     
//bar
else     
//baz

se puede escribir como ternario usando el operador ternario:

foo ? bar : baz

y

while (something is true)
{
blah 
}

Se puede escribir como:

blah while(something is true)

Sin embargo, en los idiomas que no tienen este "azúcar" definitivamente incluiría las llaves. Como usted dijo, evita que se introduzcan errores innecesarios y hace más clara la intención del programador.

Answer 13

No compro tu argumento. Personalmente, no conozco a nadie que alguna vez haya "añadido accidentalmente" una segunda línea debajo de un if . Comprendería decir que está anidado if afirmaciones deberían tener llaves para evitar que se cuelguen otras cosas, pero como lo veo, está imponiendo un estilo debido a un temor de que, IMO, esté fuera de lugar.

Answer 14

No estoy diciendo que no sea razonable, pero en más de 15 años de codificación con lenguajes tipo C, no he tenido un solo problema con omitir las llaves. Comentar una rama suena como un problema real en teoría, nunca lo he visto en la práctica.

Answer 15

Otra ventaja de usar llaves siempre es que facilita la búsqueda y reemplazo y operaciones automatizadas similares.

Por ejemplo: supongamos que me doy cuenta de que generalmente se llama a la functionB B inmediatamente después de la functionA , con un patrón similar de argumentos, por lo que quiero refactorizar ese código duplicado en una nueva función de combined_function . Una expresión regular podría manejar fácilmente esta refactorización si no tiene una herramienta de refactorización lo suficientemente potente ( ^/s+functionA.*?;/n/s+functionB.*?; ) pero, sin llaves, un simple enfoque de expresión regular podría fallar :

if (x)
  functionA(x);
else
  functionA(y);
functionB();

se convertiría

if (x)
  functionA(x);
else
  combined_function(y);

Las expresiones regulares más complicadas funcionarían en este caso particular, pero me ha resultado muy útil poder usar los scripts de Perl de búsqueda y reemplazo basados ​​en expresiones regulares, y el mantenimiento de código automatizado similar, por lo que prefiero un estilo de codificación Eso no hace que sea innecesariamente complicado.

Answer 16

Para cosas como esta, recomendaría crear una plantilla de configuración para el autoformatter de IDE. Luego, cuando sus usuarios presionen alt-shift-F (o cualquiera que sea la pulsación de tecla en su IDE de elección), las llaves se agregarán automáticamente. Luego diga a todos: "adelante, cambie la coloración de la fuente, la configuración de PMD o lo que sea. Sin embargo, no cambie las reglas de sangría o de refuerzo automático".

Esto aprovecha las herramientas que tenemos disponibles para evitar discutir sobre algo que realmente no vale la pena el oxígeno que normalmente se gasta en él.

Answer 17

Prefiero agregar llaves a condicionales de una sola línea para el mantenimiento, pero puedo ver cómo hacerlo más limpio se ve más limpio. No me molesta, pero algunas personas podrían apagarse por el ruido visual adicional.

Tampoco puedo ofrecer un contraargumento mejor. ¡Lo siento! ;)

Answer 18

Si tiene tiempo para leer todo esto, entonces tiene tiempo para agregar llaves adicionales.

Answer 19

Todavía no tengo a nadie que tenga una buena razón para no usar siempre llaves.

Los beneficios superan con creces cualquier razón "me siento fea" que he escuchado.

El estándar de codificación existe para facilitar la lectura y reducir los errores.

Este es un estándar que realmente vale la pena.

Answer 20

Veo esta regla como una exageración. Los estándares draconianos no son buenos programadores, solo disminuyen las probabilidades de que un bobo haga un desastre.

Los ejemplos que das son válidos, pero tienen mejores soluciones que forzar llaves:

Cuando no preparas una sola línea y luego alguien la comenta, estás en problemas.

Dos prácticas resuelven esto mejor, elige una:

1) Comente el if , while , etc. antes del one-liner con el one-liner. Es decir, tratar

if(foo)
    bar();

como cualquier otra declaración multilínea (por ejemplo, una asignación con múltiples líneas, o una llamada de función de múltiples líneas):

//if(foo)
//    bar();

2) Prefijo el // con una ; :

if(foo)
;//    bar();

Si no se ajusta a una sola línea y la sangría no se muestra igual en la máquina de otra persona ... está en problemas.

No tu no eres; El código funciona igual pero es más difícil de leer. Arregla tu sangría. Escoge las pestañas o los espacios y quédate con ellos. No mezcle las pestañas y los espacios para la sangría. Muchos editores de texto lo solucionarán automáticamente.

Escribe un código de Python. Eso arreglará al menos algunos malos hábitos de sangrado.

Además, las estructuras como } else { parecen una versión nethack de un luchador TIE para mí.

¿Existen buenas razones por las que esto sería un estándar erróneo o irrazonable? Ha habido cierta discusión al respecto, pero nadie puede ofrecerme un contraargumento mejor que "se siente feo".

Aparatos redundantes (y paréntesis) son el desorden visual. El desorden visual hace que el código sea más difícil de leer. Cuanto más difícil es leer el código, más fácil es ocultar los errores.

int x = 0;
while(x < 10);
{
    printf("Count: %d/n", ++x);
}

Forzar llaves no ayuda a encontrar el error en el código anterior.

PD: estoy suscrito a la escuela "todas las reglas deben decir por qué" o, como lo expresó el Dalai Lama, "conoce las reglas para que puedas romperlas".

Answer 21

Dependiendo del idioma , no es obligatorio tener llaves para una instrucción condicional o bucle de línea única. De hecho, los eliminaría para tener menos líneas de código.

C ++:

Versión 1:

class InvalidOperation{};

//...
Divide(10, 0);
//...
Divide(int a, in b)
{
   if(b == 0 ) throw InvalidOperation();
   return a/b;
}

Versión 2:

class InvalidOperation{};

//...
Divide(10, 0);
//...
Divide(int a, in b)
{
   if(b == 0 )
   { 
      throw InvalidOperation();
   }
   return a/b;
}

DO#:

Versión 1:

foreach(string s in myList)
   Console.WriteLine(s);

Versión 2:

foreach(string s in myList)
{
   Console.WriteLine(s);
}

Dependiendo de su perspectiva, la versión 1 o la versión 2 serán más legibles. La respuesta es bastante subjetiva .