standard - java code style

¿Está bien si omito llaves en Java?

Question

He buscado esto, pero no he podido encontrar una respuesta y, por la razón que sea, estaba demasiado avergonzado de preguntarle al profesor, debido a esa sensación cuando cientos de personas te miran fijamente ...

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 tiendo a hacer mucho, debido a la visibilidad), ¿eso cambiará algo, cualquier cosa? Como dije, sé que funciona, lo probé una docena de veces, pero ahora algunas de mis asignaciones de uni son cada vez más grandes, y por alguna razón tengo un miedo irracional a que a la larga, esto puede causar algunos problemas. ¿Hay alguna razón para temer eso?

Answer 1

Creo que perder las llaves es bueno, si también está usando el formato automático, ya que 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, raro o ilegible es simplemente incorrecto, ya que el lenguaje completo se basa en esa idea, y es bastante popular (Python).

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

Answer 2

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

A veces me salteo el uso de llaves en cláusulas de guardia para hacer que el código sea más compacto. Mi requisito para esto es que sean declaraciones if que estén seguidas por una declaración de salto , como return o 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 necesariamente están en la parte superior del cuerpo del método.

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

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

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

Answer 3

Hoy en día, es muy fácil volver a sangrar códigos para descubrir qué bloque de códigos está en el cual if o for / while . Si insiste en que volver a sangrar es difícil de hacer, los paréntesis colocados en una sangría incorrecta pueden confundirlo igualmente mal.

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 descompondrá en poco tiempo. Incluso con corchetes, depende de la sangría para encontrar visualmente el inicio y el final de los bloques de códigos.

Si la sangría es importante, entonces ya debe 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 indentación descuidado (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 así puede confundirse con dicha 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.

Answer 4

Más apoyo para mí del grupo "siempre apoyos". Si omite llaves para bucles / ramificaciones de declaración única, coloque la instrucción en la misma línea que la instrucció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 llaves cuando el cuerpo está expandido. Aún así, use curlies de todos modos.

Answer 5

No cambiará nada, aparte del 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 esto:

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 en cada compañía para la que he trabajado han requerido esto, lo que no quiere decir que algunas otras compañías no tengan convenciones diferentes ...

Y en caso de que pienses que nunca marcará la diferencia: tuve que arreglar un error una vez que era más o menos equivalente al código anterior. Fue notablemente 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 hecho que fuera más fácil de diagnosticar).

Answer 6

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, piensa que do_something_else() se llama dentro del ciclo. (Y eso lleva a sesiones de depuración que rayan la cabeza).

Hay un segundo problema que la versión de llave 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.

Answer 7

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

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

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

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

Digamos que arregla el problema y despliega este código (y tal vez el revisor y cree que esto no causará ningún problema ya que no está dentro de la condición ''Prod''). Mágicamente, sus registros de producción ahora imprimen 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 permita si alguno de ellos (con intenciones maliciosas) se apodera de esta información.

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

Answer 8

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

Answer 9

Si quita llaves, solo leerá la primera línea de instrucción. Cualquier línea adicional no será leída. Si tiene más de 1 línea de instrucción para ser ejecutada, por favor use llaves, de lo contrario se lanzará una excepción.

Answer 10

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 afirmaciones, pero solo entra la primera declaración dentro del ciclo, pero no la segunda.

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

Answer 11

Si tiene un enunciado único, puede omitir los corchetes, para más de un corchetes de enunciados es necesario declarar un bloque de código.

Cuando usas paréntesis estás declarando un bloque de código:

{
//Block of code
}

Los corchetes se deben usar también con una sola instrucción cuando se encuentre 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()
}
}

Answer 12

Si usa corchetes, su código es más legible. Y si necesita agregar un operador en el mismo bloque, puede evitar posibles errores

Answer 13

Usando los corchetes futuros prueba el código contra modificaciones posteriores. He visto casos en los que se omitieron los corchetes y luego alguien 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 pensaron que era. Así que creo que la respuesta es que es una buena práctica a la luz de los cambios futuros en el código. He visto que los grupos de software lo adoptan como estándar, es decir, que siempre requieren paréntesis, incluso con bloques de una sola línea, por ese motivo.

Answer 14

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

Answer 15

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

Answer 16

En lo que respecta al resultado, es lo mismo.

Solo dos cosas para considerar.

- Mantenibilidad del código
- Código débilmente acoplado. (puede ejecutar algo más, porque no ha especificado el alcance del bucle).

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