Buenas prácticas en Java

Las buenas prácticas en Java (como en cualquier otro lenguaje) tienen como finalidad desarrollar un código más óptimo de cara al rendimiento, la homogeneidad y mantenibilidad del mismo.

Hacer un uso correcto de comentarios es de gran utilidad para explicar el propósito del mismo, funcionamiento completo y el resultado esperado.

El código debe estar identado (tabulado) y debe ser legible ya que facilitará el mantenimiento del mismo.

Convenciones de nomenclatura generales

1. Los nombres de paquetes deberían estar totalmente en minúsculas. Esto se basa en la convención especificada por Sun para la nomenclatura de paquetes.
2. Los nombres que representan tipos deben ser sustantivos y deben escribirse con mayúsculas y minúsculas iniciando con mayúscula.
3. Los nombres de variables deben utilizar mayúsculas y minúsculas iniciando con minúscula.
4. Los nombres que representan constantes (variables finales) deben estar totalmente en mayúsculas utilizando subrayados (guión bajo) para separar las palabras.
5. Los nombres que representan métodos deben ser verbos y escribirse con mayúsculas y minúsculas iniciando con minúscula.
6. Las abreviaturas y acrónimos no deberían estar con mayúsculas cuando se usan como nombre.
7. Variables privadas de clase. Las variables privadas de clase deberían tener como prefijo un guión bajo (_).
8. Las variables genéricas deberían tener el mismo nombre que su tipo.
9. Todos los nombres deberían escribirse en inglés. El inglés es el lenguaje preferido para el desarrollo internacional.

Convenciones de nomenclatura específicas

1. Los términos get/set se deben utilizar cuando un atributo se accede directamente.
Esta es la convención de nomenclatura para los métodos accesores utilzada por Sun en los paquetes predefinidos de Java. Cuando se escribe Java Beans esta convención en realidad es obligatoria para los métodos.
2. El prefijo is debería usarse para las variables y métodos booleanos.
El uso del prefijo is resuelve el problema de elegir mal los nombres booleanos como status o flag. isStatus o isFlag simplemente no encajan y el programador se ve forzado a elegir otro nombre con mayor sentido. Hay unas cuantas alternativas que encajan mejor que el prefijo is en algunas situaciones. Estos son los prefijos has, can, y should.
3. El término compute se puede utilizar en métodos donde algo se calcula.
4. El término find se puede utilizar en los métodos donde se está buscando algo.
5. El término initialize se puede utilizar donde se establece un concepto u objeto.
6. La forma plural debería utilizarse en nombres que representen una colección de objetos.
7. El prefijo n debería utilizarse para variables que representen un número de objetos.
8. Las variables Iterator deberían llamarse i, j, k, etc. Esta notación es tomada de las matemáticas donde hay una convención establecida para indicar a los iteradores. Las variables con nombre j, k, etc. deberían usarse solo para iteraciones anidadas.
9. Deben evitarse las abreviaciones en los nombres.
10. Por otro lado hay frases específicas difundidas que se conocen más por su acrónimo o abreviación. Estas frases deberían mantenerse abreviadas. Por ejemplo: html, cpu.
11. Las variables booleanas negadas deben evitarse.
12. Las constantes (variables finales) asociadas deben prefijarse con un nombre de tipo común. Por ejemplo: COLOR_RED, COLOR_GREEN

Archivos

1. Los archivos fuente de Java deberían tener la extensión .java.
2. Las clases deberían declararse en archivos individuales con un nombre de archivo que concuerde con el nombre de la clase. Las clases privadas secundarias pueden declararse como clases internas y residir en el archivo de la clase a la que pertenecen. Esto es apoyado por las herramientas de Java.
3. El contenido del archivo debe mantenerse en 80 columnas. 80 columnas es es la dimensión común para los editores, emuladores de terminal, impresoras y depuradores; los archivos que se comparten entre varios desarrolladores deberían alinearse a estas restricciones. Cuando el archivo pasa por varios programadores, se mejora la legibilidad cuando se evitan los cortes de línea sin intención.
4. Debe evitarse caracteres especiales como TAB y salto de página. Estas características tienden a causar problemas en los editores, impresoras, emuladores de terminales o depuradores cuando se usan en entornos multi-plataforma y/o multi-programador.
5. Debe evidenciarse cuando una línea está incompleta por estar partida.

Sentencias

1. La sentencia package debe ser la primera sentencia del archivo.
2. La sentencia import debe seguir a las sentencia package.
3. Las declaraciones de clase deberían organizarse. Esto debería hacerse de la siguiente manera:
3.1 Documentación de la Clase/Interface.
3.2 Sentencia class o interface.
3.3 Variables de clase (estáticas) en el orden public, protected, package (sin modificador de acceso), privadas.
3.4 Variables de instancia en el orden public, protected, package (sin modificador de acceso), private.
3.5 Constructores.
3.6 Métodos (sin orden específico).
4. Los modificadores de métodos deberían darse en el siguiente orden: <acceso> static abstract synchronized <inusual> final native.
El modificador <acceso> (si existe) debe ser el primer modificador.
<acceso> es public, protected, o private mientras que <inusual> incluye volatile y transient. Lo más importante aquí es mantener el modificador acceso como el primer modificador. De entre los posibles modificadores, este es por lejos el más importante y debe estar al inicio en la declaración del método. Para otros modificadores, el orden es menos importante, pero es conveniente tener una convención fija.
5. Las conversiones de tipos deben hacerse siempre explícitas. Nunca caiga en conversiones implícitas.
floatValue = (float) intValue; // NOT: floatValue = intValue;

Variables

1. Las variables deberían inicializarse donde se declaran y deberían declararse en el ámbito más pequeño posible. Esto asegura que las variables son válidas en todo momento. A veces es imposible inicializar una variable con un valor válido donde se le declara. En esos casos debería dejarse sin inicializar en vez de darle un valor sin sentido.
2. Las variables nunca deben tener significado dual. Esto mejora la legibilidad asegurando que todos los conceptos se representan de manera única. Reduce las posibilidades de errores producto de la dualidad.
3. Las variables de clase nunca se deberían declarar public. El concepto de ocultamiento de información y encapsulamiento de Java es violado por las variables públicas. Use las variables privadas y acceda en vez de ello a las funciones.
4. Las variables relacionadas del mismo tipo se pueden declarar en una sentencia común. Las variables no relacionadas no se deberían declarar en la misma sentencia.

Fuente: edmundoogaz

about author

1 Comentarios on "Buenas prácticas en Java"