¿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.

Leí en alguna parte que los autores de algún libro querían que su código tuviera el siguiente formato:

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

Pero las limitaciones de espacio de su editor significaron que tenían que usar esto:

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

Ahora no sé si eso es cierto (ya que no puedo encontrarlo más), pero este último estilo es muy frecuente en los libros.

A nivel personal, prefiero los corchetes en una línea separada como:

a) indican un nuevo alcance
b) es más fácil de detectar cuando tiene una falta de coincidencia (aunque esto es un problema menor en un IDE que resalta los errores para usted).

Ah, el estilo de un verdadero aparato ortopédico .

Tiene todo lo necesario para un Camino Santo, incluso un profeta (Richard "mi camino o la carretera" Stallman).

El tipo estaba tan equivocado acerca de tantas cosas, pero GNU es perfecto cuando se trata de aparatos ortopédicos.

[Actualización] He visto la luz, y ahora adoro a Allman

Segundo ejemplo, soy muy grande en cuanto a legibilidad. No puedo soportar mirar si los bloques de otra manera = (

Respuesta simple: ¿qué es más fácil de depurar?

// Case 1:
void dummyFunction() {
  for (i = 0; i != 10; ++i) {
    if (i <= 10)
      std::cout << "i is: " << i << "\n";
      std::cout << 10 - i << " steps remaining\n";

      // Some hard work here
      // which is really hard
      // and does take some screen estate
    }
    else
      std::cout << "We'll never get there";
  }
} // COMPILER ERROR HERE


// Case 2:
void dummyFunction()
{
  for (i = 0; i != 10; ++i)

    if (i <= 10)
    {
      std::cout << "i is: " << i << "\n";
      std::cout << 10 - i << " steps remaining\n";

      // Some hard work here
      // which is really hard
      // and does take some screen estate
    }
    else
      std::cout << "We'll never get there\n";
  }
} // COMPILER ERROR HERE

¿En qué caso diagnosticó el problema primero?

No me interesan mucho las preferencias personales (hay muchos otros estilos, incluyendo whitesmith y otros) y no me importan mucho ... siempre que no obstaculice mi capacidad de leer el código y depurarlo .

En cuanto al argumento del "espacio de desperdicio", no lo compro: tiendo a agregar líneas en blanco entre los grupos lógicos de todos modos para aclarar el programa ...

No es que nadie lo note, pero esta es la razón por la cual los frenos pertenecen a la misma línea que el condicional (excepto para condicionales muy largos, pero ese es un caso límite):

En C, esta es una construcción válida:

mientras (verdadero);
{
    char c;
    getchar (); // Espera entrada
}

¡Rápido! ¿Qué hace este código? Si respondiste "bucle infinito pidiendo entrada", ¡estás equivocado! Ni siquiera llega a la entrada. Queda atrapado en while(true). Observe ese punto y coma al final. Este patrón es en realidad más común de lo que parece que debería ser; C requiere que declare sus variables al comienzo de un bloque, por lo que se inició una nueva.

Una línea de código es un pensamiento. Las llaves son parte del pensamiento que contiene el condicional o el bucle. Por lo tanto, pertenecen a la misma línea.

Me gusta el primer método Parece IMO más ordenado, y es más compacto, lo que me gusta.

EDITAR: Ah, un tercero. Me gusta ese mejor cuando sea posible, ya que es aún más pequeño / ordenado.

Podrías escribirlo:

you.hasAnswer() ? you.postAnswer() : you.doSomething();

Para responder la pregunta; Solía ​​preferir llaves en su propia línea, pero, para evitar tener que pensar en los errores de la inserción automática de punto y coma en los navegadores, comencé a usar el estilo egipcio para javascript. Y cuando codifiqué java en eclipse, no tenía interés en pelear (o configurar) el estilo de llave predeterminado, así que también fui con egipcio en ese caso. Ahora estoy bien con ambos.

Casi todas las respuestas aquí están diciendo alguna variación en "Hagas lo que hagas, quédate con uno o dos".

Así que lo pensé por un momento y tuve que admitir que simplemente no lo veo tan importante. ¿Alguien puede decirme honestamente que lo siguiente es difícil de seguir?

int foo(int a, Bar b) {
    int c = 0;
    while(a != c)
    {
        if(b.value[a] == c) {
            c = CONST_A;
        }
        c++;
    }
    return c;
}

No estoy seguro de nadie más ... pero tengo absolutamente cero problemas para cambiar mentalmente de un estilo a otro. Me tomó unos momentos descubrir qué hizo el código, pero ese es el resultado de que escribí aleatoriamente una sintaxis tipo C. :)

En mi opinión no tan humilde, abrir llaves es casi completamente irrelevante para la legibilidad del código. Hay algunos casos de esquina enumerados anteriormente donde un estilo u otro hace la diferencia, pero en su mayor parte, el uso prudente de las líneas en blanco lo limpia.

FWIW, nuestros estilos de codificación en el trabajo utilizan una forma 1 un poco más estructurada y una forma modificada 3. (C ++)

            // blank line is required here
if (x) {
            //This blank line is required
   y = z;
}
            // blank line is required here too, unless this line is only another '}'

if (x) y = z; //allowed

if (x)
    y = z;  // forbidden

Tengo curiosidad si aquellos que prefieren la forma 2 encontrarían mejor esta versión de la forma 1, solo porque la línea en blanco proporciona una separación visual más fuerte.

Me sorprende que esto no se haya planteado todavía. Prefiero el segundo enfoque porque te permite seleccionar el bloque más fácilmente.

Cuando las llaves comienzan y terminan en la misma columna y en su propia línea, puede seleccionar desde el margen o con el cursor en la columna 0. Esto generalmente equivale a un área más generosa con la selección del mouse o menos pulsaciones de teclas con la selección del teclado.

Originalmente trabajé con llaves en la misma línea que el condicional, pero cuando cambié, encontré que aceleraba la velocidad a la que trabajaba. No es de día ni de noche, por supuesto, pero es algo que lo retrasará un poco al trabajar con aparatos ortopédicos junto a sus condicionales.

Personalmente me gusta la segunda forma.

Sin embargo, la forma en que voy a demostrar es, en mi opinión, ¡la mejor porque da como resultado una mayor seguridad laboral! Un compañero de mi universidad me pidió ayuda con su tarea y así es como se veía su código. Todo el programa parecía un solo bloque. Lo interesante es que el 95% de los errores en el programa que hizo provienen de llaves no coincidentes. El otro 5% fue obvio una vez que se combinaron las llaves.

while(1){
i=0;
printf("Enter coded text:\n");
while((s=getchar())!='\n'){
         if(i%1==0){
            start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!");
exit(1);}
input=start;}
      input[i++]=s;}
start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!!!");
exit(1);}
input=start;
input[i]='\0';
                puts(input);

Mi preferencia personal es el primer método, probablemente porque esa es la forma en que aprendí PHP por primera vez.

Para ifdeclaraciones de una sola línea , usaré

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

Si no lo es, you.postAnswer();pero algo mucho más largo, como you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);probablemente volveré al primer tipo:

if (you.hasAnswer) {
    you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);
}

Nunca usaré un salto de línea, y nunca usaré este método si también hay una elsedeclaración.

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

Es una posibilidad teórica, pero nunca la usaría. Esto tendría que ser convertido en

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

No deberian; primer método para mi

Cuando miro el segundo, debido a las líneas no utilizadas (aquellas que solo tienen llaves, aparte de la última llave de cierre), parece que rompe la continuidad del código. No puedo leerlo tan rápido porque necesito prestar especial atención a las líneas vacías, que generalmente significan una separación en el propósito del código o algo así, pero en ningún caso "esta línea pertenece a una llave" (que solo repite el significado de sangría).

De todos modos, al igual que cuando escribe texto ... agregar una sangría al comienzo de un párrafo es superfluo si hay una línea en blanco antes (doble signo de cambio de párrafo), no hay necesidad de desperdiciar líneas para llaves cuando estamos sangría adecuada.

Además, como ya se dijo, permite colocar más código en la pantalla, que de lo contrario es un poco contraproducente.

Depende de la plataforma / idioma / convenciones

En Java:

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

Cía#

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

Cía:

void someMethod() 
{ 
     if (you_hasAnswer()) {
         you.postAnswer();
     } else {
       you_doSomething();
     }
}

Odio cuando los chicos de Java usan su estilo en código C # y viceversa.

Todo lo que puedo decir es que si eres fanático del método # 3, serás perseguido por cada formateador de código IDE en la tierra.

Utilizo el primer método simplemente porque es más compacto y permite más código en la pantalla. Yo mismo nunca he tenido problemas para emparejar llaves (siempre las escribo, junto conif declaración antes de agregar la condición, y la mayoría de los entornos le permiten saltar a la llave correspondiente).

Si usted qué necesita para emparejar los apoyos visuales, entonces yo preferiría el segundo método. Sin embargo, eso permite menos código a la vez, lo que requiere que se desplace más. Y eso, al menos para mí, tiene un mayor impacto en la lectura del código que tener llaves cuidadosamente alineadas. Odio el desplazamiento. Por otra parte, si necesita desplazarse por una sola ifdeclaración, lo más probable es que sea demasiado grande y necesita una refactorización.

Pero; Lo más importante de todo es la consistencia. Use uno u otro, ¡nunca ambos!

Cuando estaba aprendiendo programación a los 12, puse los corchetes en la siguiente línea porque los tutoriales de codificación de Microsoft son así. También sangré con TABS de 4 espacios esa vez.

Después de unos años, aprendí Java y JavaScript, y vi más código de llaves en la misma línea, así que cambié. También comencé a sangrar con espacios de 2 espacios.

Hay una cuarta opción que mantiene los tirantes alineados, pero no desperdicia espacio:

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

El único problema es que la mayoría de los autoformadores de IDE se ahogan con esto.

Todo depende de usted, siempre y cuando no esté trabajando en un proyecto donde el gerente del proyecto haya establecido algunas restricciones de codificación o algunos estándares que todos los programadores que trabajan en ese proyecto deben seguir durante la codificación.

Yo personalmente preferiría el primer método.

Además, no obtuve lo que quieres mostrar con el tercer método.

¿No es esa una manera incorrecta? Por ejemplo, considere una situación como ...

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

Ahora, ¿qué pasa si alguien quiere agregar algunas declaraciones más en el if bloque ?

En ese caso, si usa el tercer método, el compilador arrojará el error de sintaxis.

if (you.hasAnswer())
   you.postAnswer1();
   you.postAnswer2();
else
   you.doSomething();