¿Cuál es el propósito de usar llaves (es decir, {}) para un if o loop de una sola línea?

Estoy leyendo algunas notas de mi profesor de C ++ y él escribió lo siguiente:

1. Usar sangría // OK
2. Nunca confíe en la precedencia del operador: utilice siempre paréntesis // OK
3. Utilice siempre un bloque {}, incluso para una sola línea // no está bien , ¿por qué?
4. Objeto Const en el lado izquierdo de la comparación // OK
5. Use unsigned para variables que son> = 0 // buen truco
6. Establezca el puntero en NULL después de la eliminación: doble protección de eliminación // no está mal

La tercera técnica no me resulta clara: ¿qué ganaría al colocar una línea en a { ... }?

Por ejemplo, tome este código extraño:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

y reemplazarlo con:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;

¿Cuál es el beneficio de usar la primera versión?

Intentemos modificar también icuando incrementemos j:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
        i++;

¡Oh no! Viniendo de Python, esto se ve bien, pero de hecho no lo es, ya que es equivalente a:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
i++;

Por supuesto, este es un error tonto, pero que incluso un programador experimentado podría cometer.

Otra muy buena razón se señala en la respuesta de ta.speot.is .

Un tercero en el que puedo pensar es el anidado if:

if (cond1)
   if (cond2) 
      doSomething();

Ahora, suponga que ahora quiere hacerlo doSomethingElse()cuando cond1no se cumple (nueva función). Entonces:

if (cond1)
   if (cond2) 
      doSomething();
else
   doSomethingElse();

lo cual obviamente está mal, ya que se elseasocia con lo interno if.

Editar: Dado que esto está recibiendo algo de atención, aclararé mi punto de vista. La pregunta que estaba respondiendo es:

¿Cuál es el beneficio de usar la primera versión?

Lo que he descrito. Hay algunos beneficios. Pero, en mi opinión, las reglas "siempre" no siempre se aplican. Entonces no apoyo totalmente

Utilice siempre un bloque {}, incluso para una sola línea // no está bien, ¿por qué?

No digo que siempre use un {}bloque. Si es una condición y comportamiento lo suficientemente simple, no lo haga. Si sospecha que alguien podría venir más tarde y cambiar su código para agregar funcionalidad, hágalo.

Es muy fácil cambiar accidentalmente el flujo de control con comentarios si no usa {y }. Por ejemplo:

if (condition)
  do_something();
else
  do_something_else();

must_always_do_this();

Si comenta do_something_else()con un comentario de una sola línea, terminará con esto:

if (condition)
  do_something();
else
  //do_something_else();

must_always_do_this();

Se compila, pero must_always_do_this()no siempre se llama.

Tuvimos este problema en nuestra base de código, donde alguien había entrado para deshabilitar algunas funciones muy rápidamente antes del lanzamiento. Afortunadamente lo atrapamos en la revisión de código.

Tengo mis dudas sobre la competencia del profesor. Considerando sus puntos:

1. Okay
2. ¿Alguien realmente escribiría (o querría leer) (b*b) - ((4*a)*c) ? Algunas precedentes son obvias (o deberían ser), y los paréntesis adicionales solo aumentan la confusión. (Por otro lado, debe usar los paréntesis en casos menos obvios, incluso si sabe que no son necesarios).
3. Algo así como. Existen dos convenciones amplias para formatear condicionales y bucles:

   si (cond) {
       código;
   }
   

   y:

   si (cond)
   {
       código;
   }
   

   En el primero, estaría de acuerdo con él. La apertura {no es tan visible, por lo que es mejor asumir que siempre está ahí. En el segundo, sin embargo, yo (y la mayoría de las personas con las que he trabajado) no tengo problemas para omitir las llaves para una sola declaración. (Siempre, por supuesto, que la sangría es sistemática y que usa este estilo de manera consistente. (Y muchos programadores muy buenos, que escriben código muy legible, omiten las llaves incluso cuando se formatea de la primera manera).
4. NO . Cosas como if ( NULL == ptr )son lo suficientemente feas como para dificultar la legibilidad. Escribe las comparaciones intuitivamente. (Lo que en muchos casos da como resultado la constante a la derecha). Su 4 es un mal consejo; todo lo que hace que el código no sea natural lo hace menos legible.
5. NO . Cualquier cosa menos intestá reservada para casos especiales. Para programadores con experiencia en C y C ++, el uso de unsignedoperadores de bits de señales. C ++ no tiene un tipo cardinal real (o cualquier otro tipo de subrango efectivo); unsignedno funciona para valores numéricos, debido a las reglas de promoción. Presumiblemente, los valores numéricos en los que ninguna operación aritmética tendría sentido, como los números de serie, podrían serlo unsigned. Sin embargo, argumentaría en contra porque envía un mensaje incorrecto: las operaciones bit a bit tampoco tienen sentido. La regla básica es que los tipos integrales son int, a menos que exista una razón importante para usar otro tipo.
6. NO . Hacer esto sistemáticamente es engañoso, y en realidad no protege contra nada. En estricto código OO, delete this;es a menudo el caso más frecuente (y no se puede establecer thisa NULL), y por otra parte, la mayoría deletese encuentran en los destructores, por lo que no puede acceder el puntero más adelante de todos modos. Y configurarlo NULLno hace nada con respecto a ningún otro puntero flotando. Configurar el puntero sistemáticamente para NULLdar una falsa sensación de seguridad, y realmente no te compra nada.

Mire el código en cualquiera de las referencias típicas. Stroustrup viola todas las reglas que ha dado, excepto la primera, por ejemplo.

Te sugiero que encuentres otro profesor. Alguien que realmente sabe de lo que está hablando.

Todas las otras respuestas defienden la regla 3 de su profesor.

Permítanme decir que estoy de acuerdo con ustedes: la regla es redundante y no lo recomendaría. Es cierto que teóricamente evita errores si siempre agrega llaves. Por otro lado, nunca me he encontrado con este problema en la vida real : al contrario de lo que implican otras respuestas, no me he olvidado de agregar las llaves una vez que se hicieron necesarias. Si usa la sangría adecuada, se vuelve inmediatamente obvio que necesita agregar llaves una vez que se sangra más de una declaración.

La respuesta del "Componente 10" en realidad resalta el único caso concebible en el que esto realmente podría conducir a un error. Pero, por otro lado, reemplazar el código mediante una expresión regular siempre garantiza un cuidado enorme de todos modos.

Ahora echemos un vistazo al otro lado de la medalla: ¿hay alguna desventaja en usar siempre llaves? Las otras respuestas simplemente ignoran este punto. Pero no es una desventaja: se necesita una gran cantidad de espacio vertical de la pantalla, y esto a su vez puede hacer que el código ilegible porque significa que usted tiene que desplazarse más de lo necesario.

Considere una función con muchas cláusulas de protección al principio (y sí, lo siguiente es un código C ++ incorrecto, pero en otros lenguajes esta sería una situación bastante común):

void some_method(obj* a, obj* b)
{
    if (a == nullptr)
    {
        throw null_ptr_error("a");
    }
    if (b == nullptr)
    {
        throw null_ptr_error("b");
    }
    if (a == b)
    {
        throw logic_error("Cannot do method on identical objects");
    }
    if (not a->precondition_met())
    {
        throw logic_error("Precondition for a not met");
    }

    a->do_something_with(b);
}

Este es un código horrible, y sostengo firmemente que lo siguiente es mucho más legible:

void some_method(obj* a, obj* b)
{
    if (a == nullptr)
        throw null_ptr_error("a");
    if (b == nullptr)
        throw null_ptr_error("b");
    if (a == b)
        throw logic_error("Cannot do method on identical objects");
    if (not a->precondition_met())
        throw logic_error("Precondition for a not met");

    a->do_something_with(b);
}

Del mismo modo, los bucles anidados cortos se benefician al omitir las llaves:

matrix operator +(matrix const& a, matrix const& b) {
    matrix c(a.w(), a.h());

    for (auto i = 0; i < a.w(); ++i)
        for (auto j = 0; j < a.h(); ++j)
            c(i, j) = a(i, j) + b(i, j);

    return c;
}

Comparar con:

matrix operator +(matrix const& a, matrix const& b) {
    matrix c(a.w(), a.h());

    for (auto i = 0; i < a.w(); ++i)
    {
        for (auto j = 0; j < a.h(); ++j)
        {
            c(i, j) = a(i, j) + b(i, j);
        }
    }

    return c;
}

El primer código es conciso; El segundo código está hinchado.

Y sí, esto puede mitigarse hasta cierto punto poniendo la llave de apertura en la línea anterior. Pero eso aún sería menos legible que el código sin ningún paréntesis.

En resumen: no escriba código innecesario que ocupe espacio en la pantalla.

La base de código en la que estoy trabajando está dispersa con código por personas con aversión patológica a los aparatos ortopédicos, y para las personas que vienen más tarde, realmente puede hacer una diferencia en la mantenibilidad.

El ejemplo problemático más frecuente que he encontrado es este:

if ( really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
    this_looks_like_a_then-statement_but_isn't;

Entonces, cuando llego y deseo agregar una declaración de entonces, puedo terminar fácilmente con esto si no tengo cuidado:

if ( really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
{
    this_looks_like_a_then-statement_but_isn't;
    i_want_this_to_be_a_then-statement_but_it's_not;
}

Teniendo en cuenta que se tarda ~ 1 segundo para agregar las llaves y se puede ahorrar por lo menos unos minutos confusas depuración, ¿por qué alguna vez no ir con la opción reducido ambigüedad? Me parece una falsa economía.

Mi 2c:

Usar sangría

Obviamente

Nunca confíe en la precedencia del operador: use siempre paréntesis

No usaría las palabras "nunca y" siempre ", pero en general veo que esta regla es útil. En algunos idiomas (Lisp, Smalltalk) esto no es un problema.

Utilice siempre un bloque {}, incluso para una sola línea

Nunca hago eso y nunca tuve un solo problema, pero puedo ver cómo puede ser bueno para los estudiantes, especialmente. si estudiaron Python antes.

Objeto Const en el lado izquierdo de la comparación

¿Condiciones de Yoda? No por favor. Duele la legibilidad. Simplemente use el nivel de advertencia máximo cuando compile su código.

Use unsigned para variables que son> = 0

OKAY. Curiosamente, he oído que Stroustrup no está de acuerdo.

Establezca el puntero en NULL después de la eliminación: doble protección de eliminación

¡Mal consejo! Nunca tenga un puntero que apunte a un objeto eliminado o inexistente.

Es más intuitivo y fácil de entender. Deja en claro la intención.

Y garantiza que el código no se rompa cuando un nuevo usuario podría perderlo sin saberlo {, al }tiempo que agrega una nueva declaración de código.

Para agregar a las sugerencias muy sensatas anteriores, un ejemplo que encontré al refactorizar algún código de donde esto se vuelve crítico fue el siguiente: estaba alterando una base de código muy grande para cambiar de una API a otra. La primera API recibió una llamada para establecer el Id. De la compañía de la siguiente manera:

setCompIds( const std::string& compId, const std::string& compSubId );

mientras que el reemplazo necesitaba dos llamadas:

setCompId( const std::string& compId );
setCompSubId( const std::string& compSubId );

Me puse a cambiar esto usando expresiones regulares que fue muy exitoso. También pasamos el código a través de un estilo , lo que realmente lo hizo mucho más legible. Luego, a mitad del proceso de revisión, descubrí que en algunas circunstancias condicionales estaba cambiando esto:

if ( condition )
   setCompIds( compId, compSubId );

A esto:

if ( condition )
   setCompId( compId );
setCompSubId( compSubId );

que claramente no es lo que se requería. Tuve que volver al principio para hacer esto nuevamente tratando el reemplazo como completamente dentro de un bloque y luego alterando manualmente cualquier cosa que terminara pareciendo tonta (al menos no sería incorrecto).

Noto que astyle ahora tiene la opción --add-bracketsque le permite agregar corchetes donde no los hay y lo recomiendo si alguna vez se encuentra en la misma posición que yo.

Estoy usando en {}todas partes, excepto en algunos casos donde es obvio. Una sola línea es uno de los casos:

if(condition) return; // OK

if(condition) // 
   return;    // and this is not a one-liner 

Puede dolerle cuando agrega algún método antes de regresar. La sangría indica que el retorno se está ejecutando cuando se cumple la condición, pero siempre regresará.

Otro ejemplo en C # con el uso de declaración

using (D d = new D())  // OK
using (C c = new C(d))
{
    c.UseLimitedResource();
}

que es equivalente a

using (D d = new D())
{
    using (C c = new C(d))
    {
        c.UseLimitedResource();
    }
}

El ejemplo más pertinente que se me ocurre:

if(someCondition)
   if(someOtherCondition)
      DoSomething();
else
   DoSomethingElse();

¿Con ifqué elsese emparejará? La sangría implica que el externo ifobtiene el else, pero en realidad no es así como lo verá el compilador; lo interno if obtendrá lo elsey lo externo ifno. Tendría que saber eso (o ver que se comporta de esa manera en el modo de depuración) para descubrir por inspección por qué este código puede estar fallando sus expectativas. Se vuelve más confuso si conoce Python; en ese caso, sabe que la sangría define bloques de código, por lo que esperaría que se evalúe de acuerdo con la sangría. C #, sin embargo, no da una vuelta rápida sobre el espacio en blanco.

Ahora, dicho esto, no estoy particularmente de acuerdo con esta regla de "siempre usar corchetes" en su cara. Hace que el código sea muy ruidoso verticalmente, lo que reduce la capacidad de leerlo rápidamente. Si la declaración es:

if(someCondition)
   DoSomething();

... entonces debería escribirse así. La frase "siempre usar corchetes" suena como "siempre rodear las operaciones matemáticas con paréntesis". Eso convertiría la declaración muy simple a * b + c / den ((a * b) + (c / d)), introduciendo la posibilidad de perderse un paréntesis cercano (la ruina de muchos codificadores), ¿y para qué? El orden de las operaciones es bien conocido y bien aplicado, por lo que los paréntesis son redundantes. Solo usaría paréntesis para imponer un orden de operaciones diferente al que normalmente se aplicaría: a * (b+c) / dpor ejemplo. Las llaves de bloque son similares; utilícelos para definir lo que desea hacer en casos en los que difiere del valor predeterminado y no es "obvio" (subjetivo, pero generalmente de sentido común).

Mirando las respuestas, nadie declaró explícitamente el tipo de práctica que uso, contando la historia de su código:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

Se convierte en:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0) j++;
}

Poniendo el j++en la misma línea que el if debería indicar a cualquier otra persona, "Solo quiero que este bloque se incremente j" . Por supuesto, esto solo vale la pena si la línea es lo más simplista posible, porque poner un punto de interrupción aquí, como se dice , no será muy útil.

De hecho, acabo de encontrarme con parte de la API de Twitter Storm que tiene este 'tipo' de código en Java, aquí está el fragmento relevante del código de ejecución, en la página 43 de esta presentación de diapositivas :

...
Integer Count = counts.get(word);
if (Count=null) count=0;
count++
...

El bloque de bucle for tiene dos cosas, por lo que no incluiría ese código. Es decir, nunca :

int j = 0;
for (int i = 0 ; i < 100 ; ++i) if (i % 2 == 0) j++;

Es horrible y ni siquiera sé si funciona (según lo previsto); no haga esto . Las nuevas líneas y llaves ayudan a distinguir piezas de código separadas pero relacionadas, de la misma manera que una coma o un punto y coma lo hacen en prosa. El bloque anterior es tan malo como una oración muy larga con algunas cláusulas y algunas otras declaraciones que nunca se rompen o se detienen para distinguir partes separadas.

Si realmente quiere telegrafiar a alguien más, es un trabajo de una sola línea, use un operador ternario o un ?:formulario:

for (int i = 0 ; i < 100 ; ++i) (i%2 ? 0 : >0) j++;

Pero esto está al borde del código de golf, y creo que no es una buena práctica (no me queda claro si debo poner el j ++ en un lado del :o no). Nota : no he ejecutado un operador ternario en C ++ antes, no sé si esto funciona, pero existe .

En breve:

Imagine cómo su lector (es decir, la persona que mantiene el código) interpreta su historia (código). Que sea lo más claro posible para ellos. Si sabe que el codificador / estudiante novato está manteniendo esto, tal vez incluso deje {}entrar la mayor cantidad posible, solo para que no se confundan.

Porque cuando tienes dos declaraciones sin {}, es fácil pasar por alto un problema. Supongamos que el código se ve así.

int error = 0;
enum hash_type hash = SHA256;
struct hash_value *hash_result = hash_allocate();

if ((err = prepare_hash(hash, &hash_result))) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &client_random)) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &server_random)) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &exchange_params)) != 0)
    goto fail;
    goto fail;
if ((err = hash_finish(hash)) != 0)
    goto fail;

error = do_important_stuff_with(hash);

fail:
hash_free(hash);
return error;

Se ve bien. El problema con esto es realmente fácil de pasar por alto, especialmente cuando la función que contiene el código es mucho más grande. El problema es que goto failse ejecuta incondicionalmente. Puedes imaginar fácilmente lo frustrante que es esto (haciéndote preguntar por qué hash_updatesiempre falla el último , después de todo, todo hash_updatefunciona bien)

Sin embargo, eso no significa que sea para agregar en {}todas partes (en mi opinión, ver en {}todas partes es molesto). Si bien puede causar problemas, nunca lo hizo para mis propios proyectos, ya que mi estilo de codificación personal prohíbe los condicionales sin {}cuando no están en la misma línea (sí, estoy de acuerdo en que mi estilo de codificación no es convencional, pero me gusta, y yo use el estilo de código del proyecto cuando contribuya a otros proyectos). Esto hace que el siguiente código esté bien.

if (something) goto fail;

Pero no el siguiente.

if (something)
    goto fail;

Hace que su código sea más legible al definir claramente el alcance de sus bucles y bloques condicionales. También te salva de errores accidentales.

wrt 6: es más seguro porque eliminar un puntero nulo es un no-op. Entonces, si accidentalmente pasa por esa ruta dos veces, no causará que la corrupción de la memoria libere memoria que está libre o se ha asignado a otra cosa.

Esto es principalmente un problema con los objetos de ámbito de archivo estático y los singletons que no tienen vidas muy claras y se sabe que se recrearon después de haber sido destruidos.

En la mayoría de los casos, puede evitar la necesidad de esto utilizando auto_ptrs

Me gusta la respuesta aceptada de Luchian, de hecho, aprendí por las malas que tiene razón, por lo que siempre uso llaves, incluso para bloques de una sola línea. Sin embargo, personalmente hago una excepción cuando escribo un filtro, como está en su ejemplo. Esta:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

me parece abarrotado. Separa el ciclo for y la declaración if en acciones separadas, cuando realmente su intención es una sola acción: contar todos los enteros divisibles por 2. En un lenguaje más expresivo, esto podría escribirse algo así como:

j = [1..100].filter(_%2 == 0).Count

En los idiomas que carecen de cierres, el filtro no se puede expresar en una sola declaración, sino que debe ser un ciclo for seguido de una declaración if. Sin embargo, todavía es una acción en la mente del programador, y creo que debería reflejarse en el código, así:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
  if (i % 2 == 0)
{
    j++;
}

Una opción para ayudar a prevenir los errores que se han descrito anteriormente es alinear lo que desea que suceda cuando no usa llaves. Hace que sea mucho más difícil no notar los errores cuando intentas modificar el código.

if (condition) doSomething();
else doSomethingElse();

if (condition) doSomething();
    doSomething2(); // Looks pretty obviously wrong
else // doSomethingElse(); also looks pretty obviously wrong

Si eres un compilador, no hace ninguna diferencia. Los dos son iguales.

Pero para los programadores, el primero es más claro, fácil de leer y menos propenso a errores.

Otro ejemplo de agregar llaves. Una vez que estaba buscando un error y encontré dicho código:

void SomeSimpleEventHandler()
{
    SomeStatementAtTheBeginningNumber1;
    if (conditionX) SomeRegularStatement;
    SomeStatementAtTheBeginningNumber2;
    SomeStatementAtTheBeginningNumber3;
    if (!SomeConditionIsMet()) return;
    OtherwiseSomeAdditionalStatement1;
    OtherwiseSomeAdditionalStatement2;
    OtherwiseSomeAdditionalStatement3;
}

Si lee el método línea por línea, notará que hay una condición en el método que se devuelve si no es cierto. Pero en realidad se parece a otros 100 controladores de eventos simples que establecen algunas variables en función de algunas condiciones. Y un día aparece el Codificador rápido y agrega una declaración de configuración de variables adicional al final del método:

{
    ...
    OtherwiseSomeAdditionalStatement3;
    SetAnotherVariableUnconditionnaly;
}

Como resultado, SetAnotherVariableUnconditionnaly se ejecuta cuando SomeConditionIsMet (), pero el tipo rápido no lo notó porque todas las líneas tienen un tamaño casi similar e incluso cuando la condición de retorno está indentada verticalmente no es tan notable.

Si el retorno condicional se formatea así:

if (!SomeConditionIsMet())
{
    return;
}

es muy notable y Fast Coder lo encontrará de un vistazo.

Considero que el primero es claro y luego el segundo. Da la sensación de cerrar las instrucciones, con poco código está bien cuando el código se vuelve complejo {...}ayuda mucho incluso si es endifobegin...end

//first
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}


//second
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
i++;

Es mejor establecer el puntero en NULL cuando haya terminado con él.

Aquí hay un ejemplo de por qué:

La clase A hace lo siguiente:

1. Asigna un bloque de memoria
2. Luego, algún tiempo después, elimina este bloque de memoria pero no establece el puntero en NULL

La clase B hace lo siguiente

1. Asigna memoria (y en este caso se le da el mismo bloque de memoria que fue eliminado por la clase A.)

En este punto, tanto la Clase A como la Clase B tienen punteros que apuntan al mismo bloque de memoria, en lo que respecta a la Clase A, este bloque de memoria no existe porque ha terminado con él.

Considere el siguiente problema:

¿Qué sucede si hubo un error lógico en la Clase A que resultó en la escritura en la memoria que ahora pertenece a la Clase B?

En este caso particular, no obtendrá un error de excepción de acceso incorrecto porque la dirección de memoria es legal, mientras que la clase A ahora está corrompiendo efectivamente los datos de clase B.

La clase B puede bloquearse eventualmente si encuentra valores inesperados y, cuando se bloquea, lo más probable es que pases bastante tiempo buscando este error en la clase B cuando el problema está en la clase A.

Si hubiera establecido el puntero de memoria eliminado en NULL, habría recibido un error de excepción tan pronto como cualquier error lógico en la Clase A intentara escribir en el puntero NULL.

Si le preocupa el error lógico con doble eliminación cuando los punteros son NULL por segunda vez, agregue aserción para esto.

Además: si va a rechazar el voto, explique.

Siempre tener llaves es una regla muy simple y robusta. Sin embargo, el código puede parecer poco elegante cuando hay muchas llaves. Si las reglas permiten omitir llaves, entonces debería haber reglas de estilo más detalladas y herramientas más sofisticadas. De lo contrario, puede resultar fácilmente con un código caótico y confuso (no elegante). Por lo tanto, buscar una regla de estilo individual separada del resto de guías de estilo y herramientas utilizadas es probablemente infructuoso. Solo traeré algunos detalles importantes sobre esa regla # 3 que ni siquiera se han mencionado en otras respuestas.

El primer detalle interesante es que la mayoría de los defensores de esa regla acuerdan violarla en caso de else. En otras palabras, no exigen en revisión dicho código:

// pedantic rule #3
if ( command == Eat )
{
    eat();
}
else
{
    if ( command == Sleep )
    {
        sleep();
    }
    else
    {
        if ( command == Drink )
        {
            drink();
        }
        else
        {
            complain_about_unknown_command();
        }
    }
}

En cambio, si lo ven, incluso pueden sugerir que lo escriban así:

// not fully conforming to rule #3
if ( command == Eat )
{
    eat();
}
else if ( command == Sleep )
{
    sleep();
}
else if ( command == Drink )
{
    drink();
}
else
{
   complain_about_unknown_command();
}

Eso es técnicamente una violación de esa regla ya que no hay llaves entre elsey if. Tal dualidad de la regla aparece cuando se intenta aplicarla a la base de código automáticamente con una herramienta sin sentido. De hecho, por qué discutir, simplemente deje que una herramienta aplique el estilo automáticamente.

El segundo detalle (que a menudo también olvidan los defensores de esa regla) es que los errores que pueden ocurrir nunca se deben solo a violaciones de esa regla # 3. En realidad, casi siempre implican violaciones de la regla n. ° 1 (con las que nadie discute). Nuevamente, desde el punto de vista de las herramientas automáticas, no es difícil hacer una herramienta que se queje inmediatamente cuando se infringe la regla n. ° 1, por lo que la mayoría de los errores pueden detectarse a tiempo.

El tercer detalle (que a menudo los opositores olvidan de esa regla) es la naturaleza confusa de la declaración vacía que está representada por un punto y coma. La mayoría de los desarrolladores con algo de experiencia se confundieron tarde o temprano por un punto y coma fuera de lugar o por una declaración vacía que se escribe con un punto y coma. Dos llaves en lugar de un punto y coma son visualmente más fáciles de detectar.

Tengo que admitir que no siempre se usa {}para una sola línea, pero es una buena práctica.

• Digamos que escribe un código sin paréntesis que se ve así:

  para (int i = 0; i <100; ++ i) para (int j = 0; j <100; ++ j) DoSingleStuff ();

Y después de un tiempo, desea agregar en jbucle algunas otras cosas y simplemente lo hace alineando y olvidando agregar corchetes.

• La desasignación de memoria es más rápida. Digamos que tiene un gran alcance y crea grandes matrices en el interior (sin newque estén en la pila). Esos arreglos se eliminan de la memoria justo después de que deja el alcance. Pero es posible que use esa matriz en un lugar y estará en la pila por un tiempo y será una especie de basura. Como una pila tiene un tamaño limitado y bastante pequeño, es posible superar el tamaño de la pila. Entonces, en algunos casos, es mejor escribir {}para evitar eso. NOTA: esto no es para una sola línea, sino para tales situaciones:

  if (...) {// SomeStuff ... {// no tenemos if, while, etc. // SomeOtherStuff} // SomeMoreStuff}

• La tercera forma de usarlo es similar a la segunda. Simplemente no es para hacer una pila más limpia sino para abrir algunas funciones. Si usa mutexfunciones largas, generalmente es mejor bloquear y desbloquear justo antes de acceder a los datos y justo después de terminar de leer / escribir eso. NOTA de esta manera se usa si tiene alguna propia classo structcon constructory destructorpara bloquear la memoria.

• Qué es más:

  if (...) if (...) SomeStuff (); else SomeOtherStuff (); // va al segundo si, pero la alineación muestra que está encendido primero ...

En general, no puedo decir, cuál es la mejor manera de usar siempre {}para una sola línea, pero no es nada malo hacer eso.

EDICIÓN IMPORTANTE Si escribe corchetes de compilación de código para una sola línea no hace nada, pero si su código será interpretado, ralentiza el código muy ligeramente. Muy ligeramente.

Hay varias formas posibles de escribir declaraciones de control; ciertas combinaciones de ellas pueden coexistir sin afectar la legibilidad, pero otras combinaciones causarán problemas. El estilo

if (condition)
  statement;

coexistirá cómodamente con algunas de las otras formas de escribir declaraciones de control, pero no tan bien con otras. Si las declaraciones controladas de varias líneas se escriben como:

if (condition)
{
  statement;
  statement;
}

entonces será visualmente obvio qué ifafirmaciones controlan una sola línea y cuáles controlan varias líneas. Sin embargo, si las ifdeclaraciones de varias líneas se escriben como:

if (condition) {
  statement;
  statement;
}

entonces la probabilidad de que alguien intente extender una ifconstrucción de una sola declaración sin agregar las llaves necesarias puede ser mucho mayor.

La declaración de una sola declaración en la línea siguiente iftambién puede ser problemática si la base de código hace un uso significativo del formulario

if (condition) statement;

Mi preferencia es que tener la declaración en su propia línea generalmente mejora la legibilidad, excepto en los casos en que hay muchas ifdeclaraciones con bloques de control similares, por ejemplo

if (x1 > xmax) x1 = xmax;
if (x1 < xmin) x1 = xmin;
if (x2 > xmax) x2 = xmax;
if (x2 < xmin) x2 = xmin;
etc.

en cuyo caso generalmente precederé y seguiré dichos grupos de ifdeclaraciones con una línea en blanco para separarlas visualmente de otro código. Tener una gama de declaraciones que comiencen con ifla misma sangría proporcionará una indicación visual clara de que hay algo inusual.