Java

Buenas Prácticas
Introducción
Se trata de realizar proyectos documentados, accesibles, basados en procesos y metodologías que nos ayudan a la mejora continua mejorando la redacción del código, la estructura, el funcionamiento, legibilidad y siendo capaz de establecer los objetivos.
Principios para las buenas prácticas.
Numero 1 “NO REPETIR”
No repetir, esto quiere decir extraer todolos métodos, extraer clases por delegación o por generalización, extraer y evidenciar patrones.
Numero 2 “ESTANDARIZAR”
1. Nombres
2. Formatos: líneas en blanco, sangrías, etc.
3. Comentarios
4. Arquitecturas, manejo de seguridad, herramientas patrones de diseño
5. Modularización: cuándo construimos clases, paquetes y métodos
* Código autodocumentado
Numero 3 “NoSorprender”
* Evitar lucirse
* No explicar lo obvio

Numero 4 “Legibilidad”
El código se escribe una vez y se lee muchas
Escribir código para humanos
En un texto usamos:
Títulos de distinto nivel
Sangrías
Signos de puntuación
Tipografías especiales
Consejos para hacer el código legible
1. Nombres
* Ser descriptivo
* lineasPorPagina es mejor que lpp
* DistanciaEnMetroses mejor que Distancia
* Poner antónimos en forma consistente: mayor, menor / min, max.
* No usar números: total1, total2
* Hablar en términos del problema y no de la solución
* datosEmpleado en vez de registroEmpleado
* Usar pocas abreviaturas
* Salvo en nombres muy largos: num, cant, long, max, min
* Nombres cortos son buenos en ámbitos restringidos
* Evitarsignificados ocultos
* “Long” es la longitud del documento, o -1 si no se encontró
* Que se puedan leer en algún idioma
* Casos especiales , cuando no hay nombres mejores
* i, i, k, para índices
* Por qué no canales[numero]
* Tmp, temp, para temporales y auxiliares
* Variables booleanas
* encontrado, terminado, error
* No expresarlas en forma negativa
* Que selean como verdadera o falsa: “sexo” no es buen nombre
Nombres de métodos
Que describa todo lo que hace el método
Que describa la intención (el qué) y no detalles de implementación (el cómo)
Mal ejemplo en Java: Arrays.binarySearch()
A lo sumo, se podría llamar busquedaRapida() eliminarEmpleado()
Bien
Malos sucedáneos
buscarEmpleado(), procesarEmpleado() , buscarEmpleadoEliminar(),buscEmpEl(), bee(), buscarEliminar(), findEmpleadoDelete()

Métodos y legibilidad
Tratar de que no dependan de un orden de ejecución Si no, documentarlo adecuadamente
Recursividad sólo cuando ayuda a la legibilidad
Y sólo al nivel de un método
No: A -> B -> A
Que afecte a la clase en la que está declarado
Si es así, suele tener el nombre de otra clase en su nombre
Si no, moverlo declase
Parámetros
Que no sean muchos
No más de 7, y si es menos, mejor
Que estén ordenados con algún criterio
Mantener el criterio en diferentes métodos
Chequear valores válidos a la entrada
En las referencias, ver que no estén en null
Los valores de entrada no deben cambiarse
Variables locales
Inicialización: siempre explícita
Un uso para cada variable
Que la vida de la variable sea lomás corta posible
Usar variables booleanas para guardar partes de
tests complicados if ( (anio % 400 == 0) ||((anio % 4 == 0) && (anio % 100 != 0) ) …
O métodos booleanos2c2010 18

Números mágicos
Collection c = new ArrayList(14); // 14 clientes
for (int i = 1; i <= 12; i++) … // meses del año
int[ ] horasTrabajadas = new int [5]; // de lunes a viernes
if (usuario == “JuanGómez”) …
Evitar todo “hardcodeo” o “números mágicos”
¿Por qué?
Salvo algunos 0, 1, “”, null, y cosas que no cambian

Sangrías y espacios
No tener miedo de usar espacios
x=f(a,b,c); -> x = f (a, b, c);
x=v[i+j*k]; -> x = v [i + j*k];
Separar al menos con una línea los métodos
Separar clases si van en el mismo archivo
Usar paréntesis y llaves sobreabundantes para aclarar
Usar...