Soy parte de un equipo de desarrollo de Java con un plazo de 6 semanas. Esto requiere escribir una gran cantidad de código muy rápidamente. Sin embargo, nuestro equipo de desarrollo tiene diferentes estilos de codificación. Todo, desde las convenciones de nombres hasta los métodos de abstracción, difieren entre nuestro equipo. ¿Alguien sabe de algún documento que dicte "estándares" para Java?
Para aclarar, me preguntaba si había una organización que dictara la convención de nomenclatura adecuada para variables y funciones, por ejemplo. Esto es primordial ya que con un plazo tan corto que no podemos permitirnos pasar tiempo tratando de comprender el código de los demás.
java
coding-standards
Daniel Gratzer
fuente
fuente
Realmente me estoy aferrando a la respuesta de Andrés y me estoy centrando en el aspecto que formatea de manera uniforme el código de Java.
Si está utilizando Eclipse, puede configurar su formateador Java para que se formatee automáticamente al estándar Java. El formateador de Eclipse también tiene otras configuraciones útiles, como los caracteres por línea (es decir, cuántos caracteres por línea antes de que se rompa en una nueva línea) y muchos otros. La estandarización de caracteres por línea hace que sea más fácil diferenciar el código escrito por diferentes desarrolladores sin tener muchas diferencias solo con el espaciado y los saltos de línea.
Finalmente, con Eclipse, después de haber establecido todas las configuraciones que desea, luego exporte su formateador como un archivo que pueda importar cada miembro del equipo. Entonces, si está utilizando Eclipse, le recomiendo explorar a fondo todas las opciones que formateará automáticamente y editará el código para usted, y luego compartirá la configuración con todo el equipo.
Supongo que los otros IDE principales de Java (IntelliJ y Netbeans) tienen una característica similar para exportar la configuración de formato.
fuente
Realmente. No es primordial.
Después de 30 años como consultor, he leído mucho código de muchos clientes. Es importante tener en cuenta que cada cliente (y a menudo dentro de la organización de un cliente) tiene diferentes estilos.
Después de leer tantos estilos, he aprendido esto.
El estilo no importa
Céntrese en escribir código que siempre funcione y en escribir pruebas unitarias que demuestren que siempre funciona.
Una vez que haya enviado el código de trabajo, puede disfrazarlo si se ha quedado sin errores para arreglar y mejoras para instalar.
fuente
No se preocupe por elegir un estándar universal perfecto. Todo lo que necesita es que su equipo acepte un estándar y se adhiera a él. Crea el tuyo si lo deseas, pero sé constante.
La consistencia mejora la colaboración, la colaboración mejora el código.
Incluso si la consistencia real no ayuda, el hecho de que su equipo haya trabajado juntos para llegar a un acuerdo es algo bueno. Su incapacidad para aceptar algo tan simple como las convenciones de codificación dice que puede haber mayores problemas de trabajo en equipo que acechan bajo la superficie.
fuente
El Sun Java CC mencionado anteriormente no solo tiene 13 años y algunas de sus reglas están desactualizadas (como 80 caracteres por línea), sino que tampoco define las convenciones de nomenclatura, excepto las más generales (carcasa de camello para clases, mayúsculas de bloque) para variables finales estáticas y similares).
Debe definir sus propios estándares para diferentes tipos de clases, como DAO, EJB, entidades, lo que sea que use. Sun Java CC es como una clase base abstracta destinada a extender :)
fuente
Como mencionan otros aquí, puede buscar en línea una de las pocas 'guías de estilo' populares para Java y persuadir a todos en el equipo para que se adhieran a ellas. Algunas herramientas de verificación de código en su IDE favorito podrían ayudarlo a recordarle cuándo no lo está haciendo.
Sin embargo, a veces la política está involucrada. Una vez estuve en una situación anterior en la que el desarrollador más experimentado del equipo continúa haciéndolo a su manera, incluso después de que alguien mencionó la necesidad de estandarizar. En tal situación, tal vez sea mejor observar su estilo de código y seguirlo, ya que probablemente tenga el mayor conocimiento sobre la base y los requisitos del código y es posible que no desee perder el tiempo pisándole los pies a pesar de que es difícil. Que es lo que el resto de nosotros hicimos en esa situación particular y de mala gana lo sigo.
Por lo tanto, también es importante considerar su situación.
fuente
El tío Bob muestra un estilo de codificación más moderno y actual en su libro "Código limpio". Lamentablemente no contiene una lista de artículos. Lo tienes que leer. Él mismo dice que para ver sus convenciones, hay que leer su código. El tío Bob es sin duda una especie de institución. El libro es una lectura excelente de todos modos, así que incluso si es demasiado tarde para leerlo ahora, léalo lo antes posible.
fuente
Lo que realmente importa en el código es la baja complejidad ciclomática, el pequeño alcance, la alta cohesión y la elección de identificadores expresivos. Dados estos, el código se vuelve fácil de entender y dicho código es bueno.
Le sugiero que busque en Programación espartana .
La mayoría de los estándares de codificación le dicen cómo hacer que un código mal escrito se vea bonito y la mayoría de las discusiones sobre el "estilo de codificación" son en realidad sobre el formateo. El formato de código se trata de representar visualmente la estructura de su código. Es trivial y automatizable y apenas tiene que ver con el estilo de codificación, porque el estilo de codificación no se trata de cómo representa la estructura del código, sino de cómo estructura el código.
También hay muchas guerras religiosas sobre las convenciones de nombres, aunque en realidad son solo un truco para evitar un diseño deficiente. Un nombre es bueno, si dice lo que significa. Cuanto más pequeños y claros sean sus alcances, más fácil será elegir dicho nombre.
fuente