if (condition) { /* do something */ }
else { /* do something */ }
if (condition)
/* do something */
else
/* do something */
Me dijeron que la primera instancia no era una buena idea. No tengo idea si este es realmente este caso (o para el segundo tampoco); ¿No acorta la cantidad a escribir? ¿O es porque simplemente hace un desastre?¿Son declaraciones singleline if o si las declaraciones sin llaves son una mala práctica?
Lo más recomendable es escribir código que otros puedan leer y actualizar fácilmente.
Su primera forma es cuestionable, ya que no sigue las formas que la mayoría de los desarrolladores de PHP se utilizan para:
if (condition) {
// code
} else {
// code
}
// ... or ...
if (condition)
{
// code
}
else
{
// code
}
// ... or ...
if (condition) { /* short code */ } else { /* short code */ }
// ... or ...
condition ? /* short code */ : /* short code */;
Tenga en cuenta que esto es totalmente acerca de la práctica estándar, y no necesariamente tiene sentido es — solo sobre lo que otros desarrolladores están acostumbrados a ver.
su segunda forma, más importante aún, no es tan bueno porque hace que sea fácil para otro programador para hacer este error:
if (condition)
// code A
else
// code B
// code C (added by another programmer)
En este ejemplo, el otro programador añadió code C, pero se olvidó de envolver todo el bloque else entre llaves. Esto causará problemas. Puede defenderse de esto simplemente envolviendo sus bloques if y else entre llaves.
En general, el código no legible es una mala práctica. La línea única es más eficiente en su tipeo y ahorra números de línea, pero regresa a ella dentro de un año o mientras busca errores y lo hará más difícil.
En mi opinión, sí, es una mala práctica tener declaraciones de línea única.
La computadora en realidad no le importa (por lo que puedo decir) pero siempre debe escribir su código como si fuera mantenido por un asesino en serie que sabe dónde vive.
¡Legible! Fácilmente auto discernible.
El problema que he visto es que los desarrolladores no reconocen el {} -salvo si agregan código a una de las condiciones. Ejemplo:
//before
if(something)
statement;
//after
if(something)
statement;
addedstatement;
Obviamente, esto no hará lo que esperan.
Me gustaría atribuir esto a ellos sin entender el idioma. Por lo general, no trato de adaptar mi código a personas que no conocen el idioma que estoy escribiendo. Dicho esto, si en una circunstancia particular se vuelve menos legible, los expertos aún pueden tener dificultades. –
Esas son dos líneas largas, por lo que en realidad no es una sola línea.
No hay nada de malo en una sola línea if s cuando se hace el código más fácil de leer.
Por ejemplo, algo como esto:
if (last_item) print ", and " else print ", "
es mucho mejor que
if (last_iem)
{
print ", and "
}
else
{
print ", "
}
Ambos son malos. Lo mejor es 'echo (last_item)? "y": ","; '. Y, por cierto, intente utilizar el eco. –
Mis preferencias por consistencia ...por lo que:
if(...)
{
statement 1;
statement 2;
}
else
{
statement 1;
statement 2;
}
no es diferente a:
if(...)
{
statement 1;
}
else
{
statement 1;
}
Así que siempre los utilizan porque es coherente y evita problemas olvidar a añadirlos en adelante.
Sin embargo, otras personas mirarán mi código y pensarán que es estúpido poner el {y}. Tienen sus razones, yo tengo la mía ... Me gustan mis razones más de las que me gustan :-)
Saludos :) Hago lo mismo, y por la misma razón: sin olvidar agregar los corchetes más adelante. También me gusta {en la línea nueva en lugar de si (contidion) {porque no siempre es visible. –
Esto es más estilo de codificación que cualquier otra cosa. Dicho esto, mi opinión personal es que su segundo ejemplo es potencialmente dañino. Es bastante fácil "agregar una segunda línea al bloque" accidentalmente en idiomas en los que las llaves son la única forma de crear bloques. Pero en PHP, donde existe una sintaxis alternativa, esto es aún menos probable que enciendan las señales de alarma necesarios:
if ($_GET["asdf"]==1):
/* do something */
else:
/* do something */
endif;
regla de oro: si se va a poner su "hacer algo" en una línea separada usa llaves si no vas a usar aparatos ortopédicos, ¡ponlo en la misma línea!
Para todas las declaraciones menos las más cortas, utilice las llaves y colóquelas según corresponda. Desea hacer esto por algunas razones:
Es más difícil cometer un error acerca de dónde va algo.
Es más fácil de leer.
En idiomas con instalaciones macro-expansión (por ejemplo C, C++), el hecho de incluir tirantes causará errores de lógica confusa cuando una macro que contiene varias instrucciones se expande dentro de un no arriostrado if-else.
he visto tantos código de terceros con cuestiones tontas, que prefiero utilizar llaves todo el tiempo. Dicho Nunca me he sentido bien en
if(){}
else(){}
utilizo si() {} en la misma línea cuando se trata de una instrucción corta y es solo. Si hay una persona use el largo:
if(checkSomething)
{
//dosomething
}
else
{
//doanotherthing
}
Esto es algo que realmente recuerdo de un examen del empleo de un tiempo atrás. El código fue similar a la siguiente:
if (x == 0)
x = 2;
else
print("x is: %d", x); // debugging!
x = 4;
La mayoría de la gente aquí puede detectar el error, pero que realmente pueden sustituir en cualquier cosa que desee como el "código malo" que fue insertado. El error más sutil se produce cuando tiene una "versión anterior" de algo comentado, y alguien lo descomenta, y de repente la segunda afirmación está fuera del bloque.
Básicamente, a menos que sea una pequeña prueba para aprender un concepto rápido, siempre soporte (e incluso en las aplicaciones de prueba que por lo general soporte). Simplemente no vale la pena el dolor de cabeza más tarde si no lo hago, incluso en 5-line-methods.
¿Alguna vez ha visto código como este en C o C++?
/* Warning: bogus C code! */
if (some condition)
if (another condition)
do_something(fancy);
else
this_sucks(badluck);
O bien la hendidura está mal, o el programa está libre de errores, debido a que una "cosa" se aplica siempre a la más cercana "si", a menos que utilice aparatos de ortodoncia.
(Vamos a usar Python No hay soportes, sólo espacios en blanco puro y limpio:.. P)
Una ventaja importante de la utilización de múltiples líneas es la facilidad de depuración. Si tiene una instrucción if else en una línea y el depurador le dice que la línea x estalló, es más difícil determinar qué parte de la instrucción falló. Varias líneas también hacen que sea más fácil recorrer tu código usando un depurador.
Debe poner el "si" y el "hacer algo" en líneas separadas para que su código sea más amigable con los depuradores interactivos.
Si coloca tanto "si" como "hacer algo" en la misma línea, no podrá establecer un punto de interrupción solo en la línea "hacer algo".
En realidad, estoy acostumbrado a tener frenillos en líneas separadas. – unrelativity
Esta es la segunda mejor práctica, la mejor es escribir con el mismo estilo que el autor original, aunque supongo que esto también es cierto :) – Brian
No estoy de acuerdo con el punto n. ° 2. Solo un programador realmente terrible haría algo como agregar el código C sin llaves. – rlbond