examen - ejemplo de cuestionario en javascript

Llaves de JavaScript en la nueva línea o no?

Question

En el trabajo, colocamos llaves en la siguiente línea, pero en casa, hago lo contrario. ¿Cuál prefieres? (K & R vs OTBS)

function something() {
    // ...
}

function something()
{
    // ...
}

Muchas bibliotecas de JavaScript parecen usar OTBS (un verdadero estilo de llaves). Me gustaría seguirlos por coherencia entre otros proyectos de JavaScript, pero ¿el estilo de K & R no parece más legible?

Nota: Conocemos el problema del retorno y llaves en JavaScript, que siempre será una excepción. Sin embargo, eso es solo un caso único.

Answer 1

¡Esta es una Guerra Santa a la que nunca obtendrás una respuesta utilizable! ¡Solo mantente con lo que todos los demás en el proyecto estén usando y no discutas!

Por lo que vale, soy un K & Rite. Encuentro que la OTBS pone mucho espacio visual entre una estructura de apertura y la siguiente declaración, cuando esas dos líneas a menudo están fuertemente relacionadas, por lo que se presentarían mejor juntas, sin una línea casi en blanco intermedia. Me gusta mantener mis líneas en blanco reservadas para separar bloques de declaraciones relacionadas.

En un estilo de codificación que en muchos espacios en blanco de todos modos, esto puede ser relativamente poco importante. Pero personalmente valoro la concisión, por lo que puedo mantener más del programa en pantalla.

No creo que tener el corsé abierto en una columna diferente al corsé sea un problema. Todavía es fácil ver la forma del bloque solo desde las sangrías. A menos que uses sangrías colgantes. No hagas eso. Pero esa es otra guerra santa por completo.

Answer 2

Como se afirma en muchas respuestas, es muy importante que encuentre un estilo que usted (y / o sus compañeros de equipo, si corresponde) se adhieren. Personalmente prefiero la misma línea porque he descubierto que poner llaves en la nueva línea puede generar muchas líneas casi vacías si trabajas con cierres y funciones anidadas, lo que hace que el código sea menos legible para mí (aunque, probablemente no para la mayoría de la gente...)

Answer 3

En mi opinión, depende de quién más trabajará con tu código. Si trabajas en un equipo de C # y compartes muchas responsabilidades, ponlo en una nueva línea y evita las disputas inevitables que de otro modo seguirían. Si trabajas con una gran cantidad de PHP (o programadores JS antiguos), póngalo en la primera línea por el mismo motivo.

Pero si está buscando algo más autoritario, Douglas Crockford dice que el corsé de apertura http://javascript.crockford.com/code.html debe http://javascript.crockford.com/code.html . Su razonamiento, si mal no recuerdo, es que lo hace coherente con el resto del lenguaje. Básicamente, porque este es un código válido pero (probablemente) incorrecto:

function myFunc() 
{
    return 
    {
      ok: true
    };
} 

... debes evitar universalmente llaves abiertas en una nueva línea. ¿Por qué? Porque el estilo de programación no debe llevar a una ambigüedad sintáctica.

El código de ejemplo anterior es válido porque es completamente sintácticamente correcto y no se generarán excepciones si escribe esto. Sin embargo, en lugar de devolver un objeto literal, {ok:true} , devolverá undefined y no se alcanzará el código que se encuentra debajo. Coloque los refuerzos de apertura en una línea y devolverá el objeto literal que usted estaba, tal vez, esperando.

La pregunta es, ¿encuentra ese argumento suficientemente convincente?

Answer 4

Los prefiero en la misma línea, pero sobre todo porque paso las funciones anónimas como argumentos mucho ... ahorra espacio y hace que la definición de la función parezca menos discordante. Por supuesto, esto es solo una opinión, y estoy de acuerdo con Bytecode Ninja en que la consistencia es lo más importante.

Answer 5

Ninguno de los dos es mejor que el otro. Simplemente elija uno y úselo de manera consistente.

Answer 6

Prefiero el método K & R por las mismas razones enumeradas anteriormente. Se ve más compacto, y las dos líneas relevantes se agrupan juntas.

Answer 7

Sigo la convención de codificación de JavaScript de Douglas Crockford, que se inspiró en las pautas de estilo de Sun de Java.

Aquí hay un enlace: http://javascript.crockford.com/code.html

Answer 8

Todo subjetivo Algunos son ligeramente mejores, pero la diferencia es insignificante. Lo más importante que debe hacer es mantenerse constante en todo su código.

Personalmente, prefiero el estilo escondido, con 4 pestañas "reales" de espacio.

function a() { if (b) { do; } else { do2; } }

Answer 9

Douglas Crockford da una razón para elegir el estilo ^{1 de} K & R:

Siempre utilizo el estilo K & R, poniendo { al final de una línea en lugar de al frente, ya que evita un error de diseño horrible en la declaración de return de JavaScript.

El error al que se refiere es cómo JavaScript maneja la declaración de return diferente en los siguientes dos escenarios:

return {
   ''status'': ''ok''
};

... y:

return 
{
   ''status'': ''ok''
};

El primero devolverá un objeto con una propiedad de status , mientras que el último devolverá undefined debido a la inserción de un punto y coma .

¹ Douglas Crockford: JavaScript: Las buenas partes: Estilo (página 96) - ISBN: 978-0596517748.