¿Existen convenciones de codificación Java generalizadas y modernas?

La última actualización de "Code Conventions for the Java Programming Language" de Sun fue en abril de 1999. Diez años después, mucho ha cambiado en el lenguaje y en los patrones generales de uso. ¿Hay estándares más actualizados y ampliamente adoptados?¿Existen convenciones de codificación Java generalizadas y modernas?

La mayoría de las pautas omiten especificar la codificación de archivos y las terminaciones de línea. Sun recomienda pestañas y espacios mixtos. El IDE de Eclipse se establece de manera predeterminada en el estándar de Eclipse, que es solo pestañas. El Maven style guide es solo espacios. Muchas guías de estilo, como JBoss, siguen las directrices de Sun, pero prefieren las llaves K & R en lugar de OTBS. Cada proyecto de Apache tiene su propia guía de estilo, con pequeñas diferencias entre cada uno.

Fuente

2009-09-01 brianegge

me gusta toma de Joel sobre las convenciones de codificación y de lo que se ha diseñado, pero con demasiada frecuencia terminan como la religión sin ningún pensamiento crítico sobre el por qué: http: //www.joelonsoftware.com/articles/Wrong.html – SteveD

Pestañas: si está usando cualquier editor * competente *, puede y fácilmente convertirá las pestañas en el número de espacios que desee y desee. Para alinear con precisión el código, use espacios. – Populus

He creado una lista de las mejores prácticas y convenciones de codificación de Java que utilizo regularmente en mi desarrollo diario. Las convenciones de codificación normalmente constan de 5 temas: convenciones de nombres, empaque, documentación y registro, formato de código MÁS las técnicas de codificación. Consulte el artículo en http://programmergate.com/coding-conventions/ –

La pregunta no pregunta cuál es su estilo de codificación, sino más bien para las normas de codificación existentes.

he encontrado el European Space Agency Java Coding Standards (pdf) (alt link) que parece al día y completa, aunque no estoy seguro de cómo la adopción generalizada es.

Fuente

2009-09-02 04:47:51 brianegge

"Regla 1: utilice la herramienta Apache Ant para construir automáticamente su proyecto." Supongo que eso significa que ahora hay bastantes proyectos de código abierto rotos. ;-) –

Sí, pero esto es mejor que la recomendación de Sun de 'GNUmakefile - El nombre preferido para makefiles'. En lo que respecta a los estándares, es difícil elegir un proyecto en el que el último desarrollador usó Groovy/Ruby/Maven, etc. para construir su proyecto. Puede compilar su proyecto con awk por lo que a mí respecta, siempre y cuando también proporcione o exporte un archivo ant. – brianegge

Cuatro espacios: es lo que Dios usa.

Fuente

2009-09-01 23:57:46 codingfloor

Es lo que Sun usa (para el JDK al menos). –

Gracioso, eso es lo que yo también uso;). En serio, no te preocupes por las codificaciones de archivos y las terminaciones de línea. Nunca escuché que surgiera una discusión sobre estándares de codificación. – Corehpf

Eso es dos espacios demasiados. – Apocalisp

Ray Ontko tiene un Bibliography of Java Coding Standards. Pero sería difícil identificar un solo estándar como "ampliamente adoptado".

Fuente

2009-09-02 00:12:58

Aunque puede parecer de fecha, poco se ha añadido a la propia lengua de la base (las bibliotecas han tenido una gran cantidad de una gran cantidad de adiciones sin embargo)

Aquellos que puedo recordar son en este momento son enum y genéricos, el resto ya estaba allí cuando el documento se escribió por primera vez.

Utilice siempre 4 espacios.
No utilice K & R o Allman: Si bien es perfectamente aceptable para C, C++ y C#, no siempre es el caso de Java (a menos que el proyecto haya decidido explícitamente usarlo). El uso de K & R o Allman en Java es desagradable desde el punto de vista visual, ya que no lo usaría en C.
Utilice llaves siempre, incluidas las declaraciones de una sola línea.

En general, intente no mezclar estilos entre los lenguajes de programación. Es como la pronunciación del acento en un lenguaje natural, se le puede entender, puede leer y escribir en él, y tiene un nivel funcional en el idioma, pero una pronunciación deficiente solo molestará a los hablantes nativos.

Fuente

2009-09-02 00:15:07 OscarRyz

. Siento que muchas cosas han cambiado. Tanto en términos de características, y cómo las personas usan el lenguaje. La evolución es la razón por la que HashMap no tiene Hashmap. El lenguaje ahora tiene anotaciones, importaciones estáticas, autoboxing, foreach, etc. Incluso me resulta difícil leer el código Java 1.0-1.2. Unicode es lo suficientemente común como para encontrar programas con caracteres Unicode en comentarios y cadenas. Elementos como "GNUmakefile - El nombre preferido para makefiles." Probablemente podrían eliminarse del estándar de codificación de Sun. – brianegge

¿Qué? Las convenciones oficiales de C# dicen que no se use K & R. En comparación, las convenciones oficiales de Java lo permiten. –

@brianegge Tienes razón en eso, el estilo Allman no es K & R – OscarRyz

El único estándar de codificación que realmente debe seguir es el aceptado por su equipo de proyecto. Puede que no esté de acuerdo con las pestañas en lugar de los espacios, pero si esa es la convención de codificación de su equipo, lo mejor será seguirlo.

Fuente

2009-09-02 00:18:16 akf

Al tratar de hacer que un equipo llegue a un consenso, a menudo es bastante útil tener una lista de estándares comunes, por lo que puede decir: "Creo que deberíamos adoptar el estándar X" o el "estándar Y". es utilizado por muchos otros proyectos ". De ahí la pregunta. – brianegge

Estoy de acuerdo. Cuando intentas comenzar un equipo o construir un consenso, tienes toda la razón. Desafortunadamente, como usted señala, ¡su "lista de estándares comunes" a menudo contiene conflictos! – akf

-2

BSD/Allman es el único estilo de sangría decente. Cumple con la regla básica de llaves: si se sientan en líneas diferentes, deben sentarse en la misma columna. Incluso Horstmann es tolerable en comparación con K & R.

Coloque siempre llaves si codifica en el bloc de notas. De lo contrario, debido a las características de sangría automática de su IDE, es inútil y molesto.

Fuente

2009-09-02 00:28:36 Marian

Comprobar Elements of Java Style

Fuente

2009-09-02 05:26:05

Este libro es casi tan antiguo como la guía de Sun. – brianegge

+1 Este es un libro excepcional que aún se aplica, a pesar de su antigüedad. – Mocky

considerar el uso de la utilizada por defecto por el mecanismo reformador de su IDE. Le ahorrará mucho tiempo en el largo plazo.

Activar acciones de guardado en Eclipse y marque Formatear origen para que las fuentes siempre se formateen. Esto significa que un cambio de formato solo cambia las cosas sucedidas desde la última vez que se guardó el archivo. Es bueno en el historial de control de fuente.

Naturalmente, puede tomarse su tiempo y definir su propio formato, pero suele ser más fácil usar el estándar Eclipse; está bien para nosotros.

Fuente

2009-09-02 05:47:26

convenciones Oficiales de codificación se encuentran en la siguiente dirección: http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html

Fuente

2012-11-16 19:28:07