¿La colocación del bracket afecta la legibilidad?

Question

duplicados posibles:
Formatting of if Statements
Is there a best coding style for identations (same line, next line)?
Best way to code stackoverflow style 'questions'/'tags' rollover buttons

public void Method { 

} 

o

public void Method 
{ 

} 

Además preferencia personal ¿Hay algún beneficio de un estilo sobre otro? Solía ​​jurar por el segundo método, aunque ahora uso el primer estilo para proyectos de trabajo y personales.

Por legibilidad me refiero a imaginar código en los métodos - if/else etc ...

Answer 1

Creo que es completamente subjetivo, sin embargo, creo que es importante establecer estándares de código para su equipo y que todos usen el mismo estilo. Dicho esto, me gusta el segundo (y he hecho que mi equipo lo use) porque parece más fácil de leer cuando no es tu código.

Answer 2

Sus líneas de código de recuento será considerablemente menor con la primera opción. :)

Answer 3

El primero es más pequeño en términos de número de líneas (quizás por eso el desarrollo -Java- libros tienden a utilizar esa sintaxis)

segundo es, en mi humilde opinión más fácil de leer como siempre lo hace dos Alineados soportes.

De todos modos ambos son ampliamente utilizados, es una cuestión de sus preferencias personales.

Answer 4

En los viejos tiempos solíamos usar el primer estilo (K & estilo R) porque las pantallas eran más pequeñas y el código a menudo se imprimía en este material llamado papel.

En estos días tenemos pantalla grande y el segundo método (estilo ANSI) hace que sea más fácil ver si sus corchetes coinciden.

Consulte HERE y HERE para obtener más información.

Answer 5

Utilizo la sentencia if como algo para razonar en este tema tan emotivo.

if (cond) { 
    //code 
} 

con solo preguntar ¿cómo se ve la afirmación else? La extensión lógica de lo anterior es: -

if (cond) { 
    //code 
} else { 
    //more code 
} 

¿Es legible? No lo creo y es simplemente feo también.

Más líneas es! = Menos legible. Por lo tanto, iría con su última opción.

Answer 6

Google C++ Style Guide sugiere

Tipo de valor devuelto en la misma línea como nombre de la función, los parámetros en la misma línea si se ajustan.

Funciones este aspecto:

ReturnType ClassName::FunctionName(Type par_name1, Type par_name2) { 
    DoSomething(); 
    ... 
} 

---

WebKit Coding Style Guidelines sugiere

Las definiciones de funciones: lugar cada soporte en su propia línea.

Derecha:

int main() 
{ 
    ... 
} 

incorrecto:

int main() { 
    ... 
} 

Sugieren llaves-on-misma línea para todo lo demás, sin embargo.

---

GNU Coding Standards sugiere

Es importante poner la llave de apertura que inicia el cuerpo de una función C en la columna uno, para que puedan comenzar una definición de función. Varias herramientas buscan llaves abiertas en la columna uno para encontrar el comienzo de las funciones C. Estas herramientas no funcionarán en el código no formateado de esa manera.

Evite colocar corchetes abiertos, paréntesis abiertos o corchetes abiertos en la columna uno cuando están dentro de una función, para que no comiencen un defun. El paréntesis abierto que inicia un cuerpo de estructura puede ir en la columna uno si le parece útil tratar esa definición como un defun.

También es importante que las definiciones de funciones comiencen el nombre de la función en la columna uno. Esto ayuda a las personas a buscar definiciones de funciones y también puede ayudar a que ciertas herramientas las reconozcan. Por lo tanto, utilizando la sintaxis de C estándar, el formato es el siguiente:

static char * 
concat (char *s1, char *s2) 
{ 
    ... 
} 

o, si desea utilizar la sintaxis de C tradicional, dar formato a la definición de esta manera:

static char * 
concat (s1, s2)  /* Name starts in column one here */ 
    char *s1, *s2; 
{      /* Open brace in column one here */ 
    ... 
} 

---

Como puede ver, todos tienen sus propias opiniones. Personalmente, prefiero las llaves Perl-ish-en-la-misma-línea-excepto-para-else, pero mientras todos los que trabajen en el código puedan cooperar, realmente no importa.

Answer 7

Personalmente encuentro el segundo más legible (curlys alineados).

Siempre es más fácil para un equipo ir con los valores predeterminados, y dado que Visual Studio y yo estamos de acuerdo en esto, esa es mi discusión. ;-)