¿Está bien si omito las llaves en Java? [cerrado]

He buscado esto, pero no pude encontrar una respuesta y por alguna razón estaba demasiado avergonzado para preguntarle al profesor, debido a ese sentimiento cuando cientos de personas te miran ...

De todos modos, mi pregunta es ¿cuál es la importancia de tener corchetes? ¿Está bien si los omito? Ejemplo:

for (int i = 0; i < size; i++)  {
   a += b;
}

vs

for (int i = 0; i < size; i++)
   a += b;

Sé que ambos funcionarán, pero si omito los corchetes (que suelo hacer mucho debido a la visibilidad), ¿cambiará algo, algo en absoluto? Como dije, sé que funciona, lo probé una docena de veces, pero ahora algunas de mis asignaciones universitarias se están haciendo más grandes y, por alguna razón, tengo un miedo irracional de que, a la larga, esto me cause algunos problemas. ¿Hay alguna razón para temer eso?

No cambiará nada en absoluto, aparte de la capacidad de mantenimiento de su código. He visto un código como este:

for (int i = 0; i < size; i++)
   a += b;
   System.out.println("foo");

lo que significa esto:

for (int i = 0; i < size; i++)
   a += b;
System.out.println("foo");

... pero que debería haber sido este:

for (int i = 0; i < size; i++) {
   a += b;
   System.out.println("foo");
}

Personalmente siempre incluyo los corchetes para reducir la posibilidad de confusión al leer o modificar el código.

Las convenciones de codificación de todas las empresas para las que he trabajado han requerido esto, lo que no quiere decir que otras empresas no tengan convenciones diferentes ...

Y en caso de que piense que nunca haría una diferencia: tuve que corregir un error una vez que era prácticamente equivalente al código anterior. Fue muy difícil de detectar ... (es cierto que esto fue hace años, antes de que comenzara las pruebas unitarias, lo que sin duda habría facilitado el diagnóstico).

El uso de llaves hace que el código sea más fácil de mantener y comprensible. Así que debería considerarlos por defecto .

A veces omito el uso de llaves en las cláusulas de guardia para hacer el código más compacto. Mi requisito para esto es que sean ifdeclaraciones seguidas de una declaración de salto , como returno throw. Además, los mantengo en la misma línea para llamar la atención sobre el idioma, por ejemplo :.

if (!isActive()) return;

También se aplican al código dentro de los bucles:

for (...) {
  if (shouldSkip()) continue;
  ...
}

Y a otras condiciones de salto de métodos que no están necesariamente en la parte superior del cuerpo del método.

Algunos lenguajes (como Perl o Ruby) tienen una especie de declaración condicional , donde no se aplican llaves:

return if (!isActive());
// or, more interestingly
return unless (isActive());

Lo considero equivalente a lo que acabo de describir, pero explícitamente respaldado por el lenguaje.

No hay diferencia. El principal problema con la segunda versión es que podrías terminar escribiendo esto:

for (...) 
  do_something();
  do_something_else();

cuando actualiza ese método, pensando que do_something_else()se llama dentro del ciclo. (Y eso lleva a sesiones de depuración de rascarse la cabeza).

Hay un segundo problema que la versión de corsé no tiene, y posiblemente sea aún más difícil de detectar:

for (int i=0; i<3; i++);
  System.out.println("Why on earth does this print just once?");

Así que mantén las llaves a menos que tengas una buena razón, son solo unas pocas teclas más.

Creo que perder las llaves es bueno, si también está utilizando el formato automático, porque su sangría siempre es correcta, por lo que será fácil detectar cualquier error de esa manera.

Decir que dejar las llaves es malo, extraño o ilegible es simplemente incorrecto, ya que todo el lenguaje se basa en esa idea y es bastante popular (Python).

Pero debo decir que sin usar un formateador puede ser peligroso.

En la mayoría de los casos, las respuestas mencionadas hasta ahora son correctas. Pero tiene algunas desventajas desde la perspectiva de la seguridad. Habiendo trabajado en un equipo de pagos, la seguridad es un factor mucho más importante que motiva tales decisiones. Digamos que tiene el siguiente código:

if( "Prod".equals(stage) )
  callBankFunction ( creditCardInput )
else
  callMockBankFunction ( creditCardInput )

Ahora digamos que este código no funciona debido a algún problema interno. Quieres comprobar la entrada. Entonces haces el siguiente cambio:

if( "Prod".equals(stage) )
  callBankFunction ( creditCardInput )
else
  callMockBankFunction ( creditCardInput )
  Logger.log( creditCardInput )

Digamos que soluciona el problema e implementa este código (y tal vez el revisor y usted cree que esto no causará un problema ya que no está dentro de la condición 'Prod') Mágicamente, sus registros de producción ahora imprimen la información de la tarjeta de crédito del cliente que es visible para todo el personal que puede ver los registros. Dios no lo quiera si alguno de ellos (con intenciones maliciosas) se apodera de estos datos.

Por lo tanto, no dar una llave y un poco de codificación descuidada a menudo puede conducir a la violación de información segura. También está clasificada como una vulnerabilidad en JAVA por CERT - Software Engineering Institure, CMU .

Si tiene una sola declaración, puede omitir los corchetes, para más de una declaración, se necesitan corchetes para declarar un bloque de código.

Cuando usa corchetes, está declarando un bloque de código:

{

//Block of code
}

Los corchetes también deben usarse con una sola declaración cuando se encuentra en una situación de declaración anidada para mejorar la legibilidad, por ejemplo:

for( ; ; )
  if(a == b) 
    doSomething()

es más legible escrito con corchetes también si no es necesario:

for( ; ; ) {
  if(a == b) {
    doSomething()
   }
}

Si usa corchetes, su código es más legible. Y si necesitas agregar algún operador en un mismo bloque puedes evitar posibles errores

El uso de corchetes prueba el código en el futuro contra modificaciones posteriores. He visto casos en los que se omitieron los corchetes y alguien más tarde agregó un código y no puso los corchetes en ese momento. El resultado fue que el código que agregaron no entró en la sección que pensaban que sí. Así que creo que la respuesta es que es una buena práctica a la luz de futuros cambios en el código. He visto grupos de software adoptar eso como estándar, es decir, siempre requieren corchetes incluso con bloques de una sola línea por esa razón.

Más apoyo de mi parte para el grupo "always braces". Si omite llaves para bucles / ramas de declaración única, coloque la declaración en la misma línea que la declaración de control,

if (condition) doSomething();
for(int i = 0; i < arr.length; ++i) arr[i] += b;

de esa manera, es más difícil olvidarse de insertar aparatos ortopédicos cuando el cuerpo está expandido. Aún así, usa rizos de todos modos.

el uso de llaves redundantes para afirmar que el código es más fácil de mantener plantea la siguiente pregunta: si los chicos que escriben, se preguntan y mantienen el código tienen problemas como los descritos anteriormente (relacionados con la sangría o la legibilidad), quizás no deberían programar en absoluto ... .

En cuanto al resultado, es lo mismo.

Solo dos cosas a considerar.

- Capacidad de mantenimiento del código
: código acoplado libremente. (puede ejecutar otra cosa porque no ha especificado el alcance del bucle).

Nota: En mi observación, si es un bucle dentro de un bucle. Inner Loop sin tirantes también es seguro. El resultado no variará.

Si solo tiene una declaración dentro del ciclo, es lo mismo.

Por ejemplo, vea el siguiente código:

for(int i=0;i<4;i++)
            System.out.println("shiva");

solo tenemos una declaración en el código anterior. así que no hay problema

for(int i=0;i<4;i++)
            System.out.println("shiva");
            System.out.println("End");

Aquí tenemos dos declaraciones, pero solo la primera declaración entra dentro del ciclo, pero no la segunda declaración.

Si tiene varias declaraciones en un solo bucle, debe usar llaves.

Si quita las llaves, solo leerá la primera línea de instrucción. No se leerán líneas adicionales. Si tiene más de 1 línea de instrucciones para ejecutar, por favor use llaves, o de lo contrario se lanzará una excepción.

Hoy en día, es muy fácil volver a sangrar códigos para saber qué bloque de códigos está en qué ifo for/ while. Si insiste en que es difícil volver a sangrar, los corchetes colocados en una sangría incorrecta pueden confundirlo igualmente.

for(int i = 0; i < 100; i++) { if(i < 10) {
    doSomething();
} else { for(int j = 0; j < 5; j++) {
        doSomethingElse();
    }
}}

Si haces esto en todas partes, tu cerebro se estropeará en poco tiempo. Incluso con corchetes, depende de la sangría para encontrar visualmente el inicio y el final de los bloques de código.

Si la sangría es importante, entonces ya debería escribir su código en la sangría correcta, para que otras personas no necesiten volver a sangrar sus códigos para leer correctamente.

Si desea argumentar que el ejemplo anterior es demasiado falso / deliberado, y que los corchetes están ahí para capturar un problema de sangría por descuido (especialmente cuando copia / pega códigos), considere esto:

for(int i = 0; i < 100; i++) {
    if(i < 10) {
    doSomething();
}
else {
    for(int j = 0; j < 5; j++) {
        doSomethingElse();
    }
}

Sí, parece menos serio que el ejemplo anterior, pero aún puede confundirse con tal sangría.

En mi humilde opinión, es responsabilidad de la persona que escribe el código verificar el código y asegurarse de que las cosas estén sangradas correctamente antes de proceder a hacer otras cosas.

también debería ser un reflejo reformatear el código ... eso es, por supuesto, para programadores profesionales en equipos profesionales

Probablemente sea mejor usar las llaves en todas partes por el simple hecho de que depurar esto sería una molestia extrema. Pero de lo contrario, una línea de código no necesita necesariamente el corchete. ¡Espero que esto ayude!