2010-12-15 11 views
12

Estoy un poco desconcertado por el número de desarrolladores que veo escribir métodos y clases con llaves debajo del nombre de la clase o el método. ¿Qué convención están siguiendo?¿Cuál es el nombre de esta convención para llaves?

Sun clearly states que la declaración correcta sería:

// this declaration follows sun's conventions 
class Sample extends Object { 

    Sample(int i, int j) { 
     .... 
    } 
} 

Sin embargo, cada vez más veo esta declarada como (incluso en los libros):

// this declaration follows a convention I cant identify 
class Sample extends Object 
{ 

    Sample(int i, int j) 
    { 
     .... 
    } 
} 

Y sé que una convención es sólo una convención y, mientras sigas a uno, todo está bien. Solo estoy buscando la respuesta en ¿qué convención hace la última declaración después de?

+4

¿No debería ahora leer como "Oracle indica claramente ..."? : P – FrustratedWithFormsDesigner

+2

A pesar de que la pregunta es claramente acerca del ** nombre de la convención **, es curioso cómo las personas ansiosas expresan sus opiniones y preferencias como respuestas fuera del tema (como [esto] (http://stackoverflow.com/) preguntas/4452288/java-conventions-for-curly-braces/4452360 # 4452360) y [this] (http://stackoverflow.com/questions/4452288/java-conventions-for-curly-braces/4452413#4452413)) o como votos en esas respuestas. – Jonik

+0

Regla 0: No te preocupes por las cosas pequeñas. Todas las posiciones de corsés estándar son igualmente válidas. Usa cualquiera de ellos que te gusteMezcla y combina. No tienen un impacto significativo en la legibilidad. No merecen ser incluidos en una convención. –

Respuesta

24

Esta es una convención de estilo estándar llamada estilo ANSI. Es común en otros idiomas además de Java, también.

+7

+1 porque respondiste la pregunta que en realidad se hacía en lugar de salir en una Jihad sobre tu estilo preferido. – JeremyP

+0

@syron simplemente perfecto! Exactamente lo que estaba buscando. ¡Gracias! – Frankie

+0

Siempre pensé que era solo el estilo de Microsoft :) –

2

Este último se parece a la Allman indent style que es muy popular en C++, pero no he visto que se usa a menudo en Java.

2

Prefiero la segunda convención porque el soporte de cierre estará directamente debajo del de apertura, por lo que es más fácil de encontrar.

0

La segunda convención es también el estilo de sangría predeterminada de Visual Studio (y por lo tanto bastante común) para C#

1

La primera convención ahorra un valioso espacio. De todos modos, el editor hace la coincidencia de corchetes.

+1

El espacio no es precioso en este día y edad. El espacio vertical aumenta la legibilidad. Me gusta poder hacer coincidir los frenillos por ojo sin tener que colocar el cursor o preocuparme por uno u otro. – JeremyP

+2

No me refería al espacio en disco. Puede ver más código en su pantalla de alta resolución cuando usa la primera convención. –

11

Como dices, lo has visto bastante, ¿no es eso una convención en sí misma, ya sea que haya o no una sola fuente o nombre para esa convención? Es muy fácil de describir, no creo que necesite una atribución particular. La página de Wikipedia "indent style" lo llama el estilo Allman Style o ANSI, pero francamente lo he estado utilizando durante años sin haber escuchado ese nombre, y no creo que saber el nombre vaya a cambiar la forma en que codigo :)

A diferencia de convenciones como la denominación de tipos y métodos públicos, la ubicación del paréntesis no tiene ningún impacto en los desarrolladores que usan la versión compilada de su código ... así que está bien (IMO) que diferentes proyectos y compañías tengan diferentes aspectos. Del mismo modo, si usar espacios o pestañas, la cantidad de espacios para sangrar, etc. Sospecho que es por eso que ha visto más variación en el apuntalamiento (y probablemente variables privadas) que en otros aspectos de la convención.

+2

El beneficio es facilitar las operaciones de control de origen como diff y merge. Cuando alguien va y reformatea archivos completos simplemente porque prefieren un estilo sobre otro, puede hacer que la fusión de la herramienta de control de origen se convierta en un dolor real. – FrustratedWithFormsDesigner

+0

@FrustratedWithFormsDesigner: Esa es la ventaja de ser coherente dentro de un proyecto, pero * no * es un beneficio para una convención entre proyectos. Si utilizo una biblioteca de terceros, no comenzaría a reformatear su código, incluso si incluí el código dentro de mi propio sistema de control de fuente. –

+0

@Jon Me temo, como muchos otros en este hilo, te has encontrado en un punto débil al leer la pregunta. Estaba buscando el nombre de la convención, solamente. Con ese conocimiento eventualmente desenterraré otros aspectos de la convención (o no si no hubiera ninguno). Sin embargo, en términos más amplios, me suscribo a todas sus respuestas. – Frankie

Cuestiones relacionadas