JavaScript llaves en línea nueva 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() 
{ 
    // ... 
} 

Una gran cantidad de bibliotecas JavaScript parece utilizar las OTB (un cierto estilo corsé). Me gustaría seguirlos por coherencia entre otros proyectos de JavaScript, pero ¿no se ve más legible el estilo R de K &?

Nota: Sabemos que el problema con el 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 & Rito. 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 un 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

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

Answer 3

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 4

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 fichas de espacio 'real'.

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

Answer 5

según se expresa en muchas respuestas, la mayoría importante que encontrar un estilo que usted (y/o sus compañeros de equipo, en su caso) se adhieren a. 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 6

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 a la misma: http://javascript.crockford.com/code.html

Answer 7

En mi opinión, depende de quién más va a trabajar con su 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ás buscando algo más autoritario, Douglas Crockford dice que la abrazadera de apertura debe always be on the top line. Su razonamiento, si mal no recuerdo, es que lo hace coherente con el resto del lenguaje. Básicamente, porque esto es válido, pero (probablemente) un código incorrecto:

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

... se debe evitar poner universalmente-llaves abiertas en una nueva línea. ¿Por qué? Debido a que el estilo de programación debe no conducir a la ambigüedad sintáctica.

El código de ejemplo anterior es válida porque es completamente sintácticamente correcta y no hay excepciones será elevado si se 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, ¿te basta con que argumento convincente?

Answer 8

Douglas Crockford da una razón para elegir el K & R estilo :

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

El error se está refiriendo a es como JavaScript se encarga de la declaración return de manera diferente en los siguientes dos escenarios:

return { 
    'status': 'ok' 
}; 

... y:

return 
{ 
    'status': 'ok' 
}; 

El primero de ellos volverán un objeto con una propiedad status, mientras que el segundo volverá undefined debido semicolon insertion.

---

Douglas Crockford: JavaScript: The Good Parts: Style (page 96) - ISBN: 978-0596517748.

Answer 9

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