PHP versus JavaScript cambiar indentación

Question

Si bien me doy cuenta de que cada idioma tiene su propia convención para la sangría, no puedo evitar estar molesto con algo que he descubierto recientemente. Tenga en cuenta este código del manual de PHP:

switch ($i) { 
    case "apple": 
     echo "i is apple"; 
     break; 
    case "bar": 
     echo "i is bar"; 
     break; 
    case "cake": 
     echo "i is cake"; 
     break; 
} 

Observe que cada caso está sangrado de la instrucción de cambio. Esto tiene sentido, ya que el código es más fácil de leer y el cuerpo del bloque está contenido en un nivel dentro de él.

Sin embargo, cuando pruebo la sentencia switch JavaScript equivalente en JSLint:

switch (i) { 
    case "apple": 
     alert("i is apple"); 
     break; 
    case "bar": 
     alert("i is bar"); 
     break; 
    case "cake": 
     alert("i is cake"); 
     break; 
} 

... se muestra un error que me dice que debería aparecer como esto en su lugar:

switch (i) { 
case "apple": 
    alert("i is apple"); 
    break; 
case "bar": 
    alert("i is bar"); 
    break; 
case "cake": 
    alert("i is cake"); 
    break; 
} 

Parece contraintuitivo, ya que cada caso ahora está en línea con el bloque del interruptor en sí mismo. No puedo imaginar ninguna razón por la que esto se considere mejor, mucho menos desencadenar un error.

¿JSLint está equivocado, o simplemente está siguiendo la convención? Si esto último es cierto, ¿por qué la convención no debería guiar por claridad?

Answer 1

Es su código. Dale formato como quieras. Use jsLint, pero si no está de acuerdo con que sus recomendaciones mejoren su código, no impleméntelos. jsLint hiere tus sentimientos.

Answer 2

Siempre que su sangría pueda justificarse lógicamente, debe sangrar en el estilo que prefiera. Si JSLint realmente se queja de esto, es demasiado pedante.

Answer 3

Es solo una convención para JS (como JSLint define la convención). Personalmente, creo que PHP estaría equivocado aquí (no sé si el manual sigue algún tipo de convención, sé que la biblioteca estándar no lo hace). Prefiero el estilo JS porque puede ser realmente desagradable si estás en unos pocos bloques anidados. Por ejemplo (código PHP):

class Foo{ 
     function Bar($arr) { 
      foreach($arr as $item) { 
       switch ($item) { 
        case "foo": 
         // Do something 
         break; 
         // You get the idea 

En última instancia, su elección. No usaría el manual de PHP como una guía de estilo; si no puede usar diferentes estilos para diferentes idiomas, use el estilo JS bien definido.

Answer 4

Si bien el formateo es importante, al final es su formateo. Hazlo como quieras El estilo particular que elija es una opción personal y muchos estilos pueden ser "buenos". Sin embargo, cualquier estilo de formato "bueno" debe ser coherente: seleccione las reglas que desee y consérvelas.

Es muy gracioso para mí ver cómo los debates se intensifican sobre cosas como colocar {en la misma línea que el código anterior o no, o "abrazar a las llaves" alrededor de un else. Creo que solo los comunistas colocan un {en la misma línea que su declaración if. :)

Answer 5

Espacio en blanco adicional se analiza en JavaScript y PHP cuando se interpretan, por lo que puede hacer que su código sea tan feo como desee. Personalmente prefiero añadir llaves adicionales para mis instrucciones switch para que no echo de menos errores de paso al siguiente:

switch ($someVar) 
{ 
    case 'value': 
    { 
    //your code here 
    } break; 
    case 'something': 
    { 
    //more code here 
    } 
    case 'something else': 
    { 
    //some more code here 
    } break; 
    default: 
    { 
    //default code here 
    } break; 
} 

escaneado el código de las llaves de fin me permite comprobar si he añadido las sentencias break correctas . Puede ver que el caso 'something' falta una declaración de interrupción (tal vez a propósito, tal vez un error).

Algunos estarán en desacuerdo con este formato, pero eso es exactamente lo que quiero decir. El formato no importa mucho. Los analizadores son bastante indulgentes. Encuentre algo que funcione para usted y cúmplalo.

Answer 6

En el libro de Crockford, afirma que los bloques no introducen un nuevo alcance. "JSLint espera bloques con instrucciones de función, si, cambiar, mientras, para, hacer y probar y en ninguna otra parte".

también que

if (condition){ 
    statements; 
} 

es el método recomendado de hacer bloques; ya que es "más resistente". Dudo mucho que haya sido estructurado de esa manera por error.

Answer 7

Es su fondo de Java escapándose. La forma JSLint imita el official Java conventions for switch case. Prefiero tu primer ejemplo, pero estoy aprendiendo a tolerar el modo JSLint.

Answer 8

También me pareció muy confuso, y encontramos este motivo en convenios Código de Douglas Crockford para el lenguaje de programación JavaScript en http://javascript.crockford.com/code.html

cláusulas (caso, captura, por defecto, de lo contrario, por fin) no son declaraciones y , por lo que no deberían sangrarse como enunciados.