tag script language php c coding-style

script - php block



¿Son las afirmaciones singleline if o las afirmaciones sin llaves una mala práctica? (12)

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 tipear? ¿O es porque simplemente hace un lío?


¿Alguna vez has visto un 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 sangría es incorrecta, o el programa tiene errores, porque un "else" siempre se aplica al "if" más cercano, a menos que use llaves.

(Solo utilicemos python. No hay paréntesis, solo espacios en blanco puros.: P)


Debe poner el "si" y el "hacer algo" en líneas separadas para hacer que su código sea más amigable para los depuradores interactivos.

Si coloca el "si" y el "hacer algo" en la misma línea, entonces no puede establecer un punto de interrupción solo en la línea "hacer algo".


El problema que he visto es que los desarrolladores no reconocen el {} -less-if cuando agregan código a una de las condiciones. Ejemplo:

//before if(something) statement; //after if(something) statement; addedstatement;

Obviamente, esto no hará lo que ellos esperan.


Esas son dos líneas largas, así que no es realmente una sola línea.

No hay nada de malo en una sola línea if es cuando hace que el código sea ​​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 ", " }


Esto es algo que realmente recuerdo de un examen de empleo hace un tiempo. El código era similar al 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 realmente puede sustituirlo en cualquier cosa que desee como el "código incorrecto" que se insertó. El error más sutil se produce cuando tiene una "versión antigua" de algo comentado, y alguien lo des-comenta, y de repente la segunda declaración está fuera del bloque.

Básicamente, a menos que sea una pequeña aplicación de prueba para aprender un concepto rápido, siempre lo coloco (e incluso en las aplicaciones de prueba que usualmente corro). Simplemente no vale la pena el dolor de cabeza más adelante si no lo hago, incluso en los métodos de 5 líneas.


Esto es más estilo de codificación que cualquier otra cosa. Dicho esto, mi opinión personal es que tu segundo ejemplo es potencialmente dañino. Es bastante fácil "agregar accidentalmente una segunda línea al bloque" en los idiomas donde las llaves son la única forma de crear bloques. Pero en PHP, donde existe una sintaxis alternativa, es incluso menos probable que active las campanas de advertencia necesarias:

if ($_GET["asdf"]==1): /* do something */ else: /* do something */ endif;

Regla de oro: si va a poner su "hacer algo" en una línea separada, use llaves; ¡Si no vas a usar tirantes, ponlo en la misma línea!


Generalmente, el código no legible es una mala práctica. La línea única es más eficiente en su escritura y guarda los números de línea, pero vuelva a ella dentro de un año o mientras está buscando errores y eso lo hará más difícil.

En mi opinión, sí, es una mala práctica tener una sola línea si las declaraciones.

A la computadora realmente no le importa (por lo que puedo decir), pero siempre debe escribir su código como si fuera un asesino en serie que sepa dónde vive.

¡Legible! Fácilmente auto-discernible.


He visto tantos códigos de terceros con problemas tontos, que prefiero usar llaves todo el tiempo. Dicho esto nunca me he sentido bien en

if(){} else (){}

Utilizo if () {} en la misma línea cuando es una instrucción corta y está solo. Si hay un uso más largo:

if(checkSomething) { //dosomething } else { //doanotherthing }


La mejor práctica es escribir código que otros puedan leer y actualizar fácilmente.

Su primer formulario es cuestionable porque no sigue los formularios a los que están acostumbrados la mayoría de los desarrolladores de PHP:

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 tiene que ver con la práctica estándar, y no necesariamente tiene sentido, solo se trata de lo que otros desarrolladores están acostumbrados a ver.

Su segunda forma, más importante, no es tan buena porque le facilita a otro programador cometer este error:

if (condition) // code A else // code B // code C (added by another programmer)

En este ejemplo, el otro programador agregó el code C , pero se olvidó de envolver el else bloque entre llaves. Esto causará problemas. Puede defenderse contra esto simplemente envolviendo sus bloques if y else entre llaves.


Mi preferencia si es por consistencia ... entonces:

if(...) { statement 1; statement 2; } else { statement 1; statement 2; }

no es diferente de

if(...) { statement 1; } else { statement 1; }

Así que siempre los uso porque es consistente y evita problemas olvidándolos de agregarlos más tarde.

Sin embargo, otras personas verán mi código y pensarán que es estúpido poner el {y}. Ellos tienen sus razones, yo tengo las mías ... Me gustan más mis razones que las suyas :-)


Para todas las declaraciones, excepto las más cortas, use las llaves y espacíelos según corresponda. Quieres hacer esto por algunas razones:

  • Es más difícil equivocarse acerca de dónde va algo.

  • Es más fácil de leer.

  • En lenguajes con facilidades de macro-expansión (por ejemplo, C, C ++), el hecho de no incluir llaves causará errores lógicos confusos cuando una macro que contiene múltiples declaraciones se expande dentro de un espacio en blanco if-else .


Un beneficio importante del uso de múltiples líneas es la facilidad de depuración. Si tiene una sentencia if else en una sola línea y el depurador le dice que la línea x ha volado, es más difícil determinar qué parte de la sentencia falló. Varias líneas también facilitan el paso a través de su código usando un depurador.