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
- OscarRyz's blog
- Inicie sesión o regístrese para enviar comentarios
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.
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.
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)
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.
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