Convenciones de escritura en Java

Siguiendo un comentario de Jose Manuel escribo acá un poco sobre las convenciones para escribir código Java, en particular sobre las llaves que van en la misma línea.

Más que obsesión es para tener consistencia en el uso del lenguaje.

El compilador no lo manda como advertencia ni nada. Es más bien para los que leen el código.

Más importante aún es tener consistencia con el equipo de trabajo. Si todo el equipo elije poner las llaves en la columna 80 esa es la convención en ese proyecto
 

A falta de convención se toma la del lenguaje que es la mencionada por José. Sobre las llaves explícitamente esta en la sección 6.4

No se menciona nada en las estructuras de control pero se ve en los ejemplos que sigue la misma. Otra cosa poco notada ( aunque si seguida por muchos que yo conozco con más experiencia ) es el usar un espacio en blanco después del if y el paréntesis para diferenciarlo de una invocación a un método.

 

Son pocos los lenguajes que hacen del formato una regla necesaria para la que un programa sea correcto, casos notable son Python y Go que lo hacen muy bien, el primero utiliza la identación para decidir cuando termina un bloque de código y en el segundo las funciones son públicas si empiezan con mayúscula.

 
 

Estas convenciones le dan un "acento" al lenguaje y es igual de horrible ver convenciones en Java aplicadas en otro lenguaje ( como C# por ejemplo )

 
Cuando lo normal es ver esto
 

Convenciones:

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de Cid

No me gustan pero hay que seguirlas

Así es cuando empece a estudiar Java siempre veía código así y se me hacía muy difícil de entender así pero bueno las convenciones son para eso para que todo mundo pueda entender y no únicamente @SrCid jejeje.

Imagen de Jose Manuel

Tu si que te dejas llevar

Tu si que te dejas llevar Oscar jajaja. Bueno, ahora ya tenemos un post para cuando se ocupe indicar las convenciones.

Imagen de ezamudio

C#

Yo siempre escribí código C# con las llaves en la misma línea, como en Java. El código que llegué a ver de ejemplos también seguía esa convención; tal vez después ya se volvió más popular el otro estilo de poner la llave en su propia línea.

O al menos esa fue la

O al menos esa fue la convención en tu proyecto. Varios proyectos opensource de Java como JBoss tenían la convención de usarlo en la misma línea. En C# al principio me parpadeaba el ojo cuando tenía que escribir un if else

 

Ya después de acostumbras y hasta se ve raro no hacerlo

De acuerdo con oscar

Es importante saber (como una vez leí que alguien dijo) que la mayor parte del tiempo de desarrollo la empleamos en leer código; es por eso que se vuelve tan importante "homologar" la manera en que el código se escribe.

Hace tiempo publiqué un ejercicio que usaba cuando hacía entrevistas para ver que nivel de comprensión de código tenia la persona. Tengo muy presente un comentario que Ezamudio me hizo en el que mencionaba que era un poco inutil a menos que se busque un compilador humano... despues dije pues ni tanto porque alguien que sabe distinguir un mal formato de código seguro es alquien que sabe escribir un codigo bien ordenado.

El punto es que (Como dice oscar) ·en cualquier lugar se pueden hacer cochinadas" y aun mas si el compilador lo permite. Tengo una malisima experiencia en mi trabajo con un compañero que le encanta dar formato de indentacion con el eclipse, valiendole chetos mi código y a lo mejor pensaran que eso está muy bien pero es horrible ver que un codigo (segun yo bien ordenado, el eclipse lo revuelve en su supuesta buena indentacion

por ejemplo, mi codigo lo escribo así

 

y eclipse me lo pone así despues del format code:
 

y es entonces cuando digo NO MAMES ese código es un asco!!
(afortunadamente pude comentarle a mi compañero no le molestó cuando le pedí que si le daba formato a su codigo con el eclipse que porfavor lo hiciera solo a sus métodos (porque desafortunadamente no tengo la autoridad para prohibírselo)

Imagen de paranoid_android

Otro tema de optimización

Cuando encuentro código legible y bien hecho es más fácil puede entenderlo y modificarlo, de otra manera pierde mucho tiempo.

Después de producido un proyecto difícilmente se querrá invertir en mejorarlo internamente la razón es porque querría alguien gastar dos veces en algo que hace lo mismo y acumular riesgo en el camino.

Por desgracia no siempre es posible cuidar de todo esto. Al final la calidad del código bien hecho queda en cada programador.
Me encantaría un foro especial de optimización, refactoring, reingeniería, proyectos de limpieza y herramientas.

Imagen de 043h68

Cárcel a los que formatean con eclipse.

Jajaja si, es horrible esforzarte un poco por dar buen formato a tu código para que el encargado de integrar solo utilice el eclipse y lo deje todo horrible ! T_T

Aunque se puede configurar eclipse o cualquier otro IDE basado en éste para que aplique el formato como a nosotros nos guste, lo pasamos al equipo de trabajo y evitamos esto. Vaya que esto podría ser en un mundo paralelo jajajaja