¿Deben aparecer llaves en su propia línea? [cerrado]

¿Deben las llaves estar en su propia línea o no? ¿Qué piensa usted al respecto?

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

o debería ser

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

o incluso

if (you.hasAnswer())
    you.postAnswer();
else
    you.doSomething();

¡Por favor se constructivo! Explique por qué, comparta experiencias, respalde con hechos y referencias.

Cuando era estudiante solía poner llaves en la misma línea, para que haya menos líneas y el código se imprima en menos páginas. Ver un solo carácter de paréntesis impreso como lo único en una línea es molesto. (medio ambiente, desperdicio de papel)

Pero al codificar aplicaciones grandes, permitir que algunas líneas con solo llaves sean asequibles, teniendo en cuenta la sensación de "agrupación" que da.

Sea cual sea el estilo que elija, sea coherente para que no se convierta en una sobrecarga para que su propio cerebro procese múltiples estilos en piezas de código relacionadas . En diferentes escenarios (como el anterior), diría que está bien usar diferentes estilos, es más fácil 'cambiar el contexto' a un alto nivel.

Nunca debes hacer el 3er método.

Ojear los frenos puede ahorrarle algunas pulsaciones de teclas la primera vez, pero el siguiente programador que aparece agrega algo a su cláusula else sin darse cuenta de que al bloque le faltan frenillos va a tener mucho dolor.

Escribe tu código para otras personas.

Durante mucho tiempo sostuve que tenían el mismo valor, o tan cerca de igual que la posible ganancia al tomar la decisión correcta estaba muy, muy por debajo del costo de discutir sobre eso.

Sin embargo, ser consistente es importante . Así que dije que volteemos una moneda y empecemos a escribir el código.

He visto a programadores resistirse a cambios como este antes. ¡Superalo! He cambiado muchas veces en mi carrera. Incluso uso diferentes estilos en mi C # que en mi PowerShell.

Hace unos años, estaba trabajando en un equipo (~ 20 desarrolladores) que decidió solicitar información y luego tomar una decisión y luego aplicarla en toda la base de código. Tendríamos 1 semana para decidir.

Muchos gemidos y ojos rodantes. Un montón de "Me gusta mi camino, porque es mejor", pero sin sustancia.

Mientras estábamos estudiando los puntos más finos de la pregunta, alguien preguntó cómo lidiar con este problema en un estilo de refuerzo en la misma línea:

void MyFunction(
    int parameterOne,
    int parameterTwo) {
    int localOne,
    int localTwo
}

Tenga en cuenta que no es inmediatamente obvio dónde termina la lista de parámetros y comienza el cuerpo. Comparar con:

void MyFunction(
    int parameterOne,
    int parameterTwo) 
{
    int localOne,
    int localTwo
}

Leímos un poco sobre cómo la gente de todo el mundo había tratado este problema, y ​​encontramos el patrón de agregar una línea en blanco después del paréntesis abierto:

void MyFunction(
    int parameterOne,
    int parameterTwo) {

    int localOne,
    int localTwo
}

Si vas a hacer un descanso visual, también puedes hacerlo con un aparato ortopédico. Entonces tus pausas visuales también se vuelven consistentes.

Editar : Dos alternativas a la solución de 'línea en blanco adicional' cuando se usa K&R:

1 / Sangrar los argumentos de la función de manera diferente del cuerpo de la función

2 / Coloque el primer argumento en la misma línea que el nombre de la función y alinee más argumentos en nuevas líneas con ese primer argumento

Ejemplos:

1 /

void MyFunction(
        int parameterOne,
        int parameterTwo) {
    int localOne,
    int localTwo
}

2 /

void MyFunction(int parameterOne,
                int parameterTwo) {
    int localOne,
    int localTwo
}

/Editar

Todavía sostengo que la consistencia es más importante que otras consideraciones, pero si no tenemos un precedente establecido , entonces prepararse en la siguiente línea es el camino a seguir.

Las reglas cardinales son:

1. Siga el estándar de codificación existente del proyecto.
2. Si no hay un estándar de codificación y está editando una base de código existente propiedad de otra persona, sea coherente con el estilo del código existente, sin importar cuánto le guste / no le guste.
3. Si está trabajando en un proyecto de campo verde, discuta con otros miembros del equipo y llegue a un consenso sobre un estándar de codificación formal o informal.
4. Si está trabajando en un proyecto de campo verde como único desarrollador, decídase y sea implacablemente coherente.

Incluso si no tiene restricciones externas, es (IMO) el mejor buscar un estándar de codificación existente (ampliamente utilizado) o una directriz de estilo, y tratar de seguirlo. Si desarrolla su propio estilo, existe una buena posibilidad de que lo lamente en unos años.

Finalmente, un estilo que se implementa / implementa usando los verificadores de estilo y los formateadores de código existentes es mejor que uno que deba "aplicarse" manualmente.

El beneficio del primer método es que es más verticalmente compacto, por lo que puede colocar más código en su pantalla, y es por eso que lo prefiero. El único argumento que escuché a favor del segundo método es que facilita emparejar corchetes de apertura y cierre, pero la mayoría de los IDE tienen un atajo de teclado para eso, y en realidad es una declaración falsa, en lugar de emparejar un corchete de apertura con un cierre corchete puede emparejar un corchete de cierre con la expresión "inicio del bloque" (if, else, for, while) en el mismo nivel de sangría, por lo que es igual de fácil determinar dónde está el inicio del bloque.

No veo ninguna razón para desperdiciar una línea completa solo para un corchete cuando la construcción anterior para / while / if ya indica visualmente el inicio de un bloque.

Dicho esto, creo que el corchete de cierre debe estar en su propia línea porque necesitamos algo para indicar el final de un bloque y su estructura de sangría de manera visible.

yo prefiero

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

terminado

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

porque la línea you.postAnswer();es mucho más fácil de leer y encontrar a primera vista. En la segunda forma, se mezcla con la línea que está arriba ( you.hasAnswer()), lo que hace que mis ojos tengan que enfocarse más para leerlo.

Prefiero el primer método Los frenos no valen totalmente la línea separada.

La cuestión es que los frenos no son importantes. Son solo basura sintáctica , que es absolutamente innecesaria para comprender para qué sirve el código, su propósito y la forma en que se implementa. Son solo un homenaje a los antiguos lenguajes tipo C donde la agrupación visual de operadores era imposible debido al bajo espacio disponible en la pantalla.

Hay lenguajes (Python, Haskell, Ruby) que están bien sin llaves. Esto solo confirma que los frenos son basura, y no debería merecer una línea para ellos siempre que sea posible:

if (you.hasAnswer()){
    you.postAnswer();
}else{
    you.doSomething();
}

Usa Python y esquiva el argumento por completo.

La posición de las llaves debe ser

metadatos

configurable en el IDE por el programador. De esa manera, esas llaves molestas en todo el código, independientemente del autor, se ven iguales.

Depende.

Si estoy codificando en Javascript o jQuery, utilizo el primer formulario:

jQuery(function($) { 
    if ($ instanceOf jQuery) { 
        alert("$ is the jQuery object!"); 
    } 
}); 

Pero si estoy codificando en C #, utilizo la segunda forma, porque esa es la forma canónica de hacerlo en C #.

public int CalculateAge(DateTime birthDate, DateTime now) 
{ 
    int age = now.Year - birthDate.Year; 
    if (now.Month < birthDate.Month 
        || (now.Month == birthDate.Month && now.Day < birthDate.Day)) 
        age--; 
    return age; 
} 

Tenga en cuenta que su ejemplo puede ser escrito

if (you.hasAnswer())
    you.postAnswer();
else
    you.doSomething();

Cía#.

Prefiero el primero porque es más difícil para mí ver el error en este ejemplo.

if (value > maximum);
{
    dosomething();
}

de lo que es en este ejemplo

if (value > maximum); {
    dosomething();
}

El ; {tiene un aspecto más mal a mí que una línea que termina con ;lo que estoy más probabilidades de notarlo.

Prefiero una ligera variante de 1)

if (you.hasAnswer()) {
    you.postAnswer();
} // note the break here
else {
    you.doSomething();
}

¿Por qué?

• Creo que siempre poner llaves en su propia línea disminuye la legibilidad. Solo puedo colocar una cierta cantidad de código fuente en mi pantalla. El estilo de soporte 2) crea algoritmos de levantamiento con muchos bucles anidados y condicionales dolorosamente largos.

• Sin embargo, quiero elsecomenzar en una nueva línea porque ify estar elsejuntos, visualmente. Si hay un soporte delante de elseél, es mucho más difícil detectar qué pertenece a qué.

• 3) se descalifica a sí mismo. Todos sabemos qué cosas malas pueden pasar si omites los corchetes y te olvidas de ello.