INTRODUCCION
● Poca densidad errores
● Facil de entender y extender
● Escribimos codigo para personas y no para maquinas
●
● Como reconocer el buen codigo del mal codigo?
● No solo lo funcional
● Simple
● Organizado
● Claro
● Facil de entender
● Facil de modificar y extender
● Creemos que la velocidad de hacer un codigo no mantenible es mayor
FUNDAMENTOS
● Dominio del problema
● Evitar notacion hungara. Antigua. Tipo de variable
● Distinciones con significado
● Interfaces vs implementaciones
Evitar prefijos o sufijos como I o Impl. Una buena practica es colocar el sufijo de la
Interfaz. Ejemplo
● Evitar mapeos mentales (variables como j, k, h no es claro)
● Utilizar sustantivos para clases
● Verbos para metodos
● No tratar de ser amigables. O informales
● No utilizar sinonimos (salvar, almacenar)
● Agregar informacion de contexto
CODIGO LIMPIO AVANZADO
● Funciones pequeñas. Única razon de cambio
● Tengan un mismo nivel de abstracción. (acceder a base de datos es diferente de
transformar un objeto en otro
● Step down rule. Leer codigo de arriba hacia abajo.
● Evitar switch statements (viola open closed principle, single responsability). Si se usa se
recomienda encapsularlo en un método o reemplazarlo x polimorfismo)
● Tener pocos argumentos. Tender a 0. A partir de 3 hay que analizarlo y replantearse
● Evitar tener parametros booleanos
●
● Utilizar objetos como argumentos
● No tener efectos de lado (Realizar tareas de las cuales no tenemos conocimiento)
● Separar la ejecucion de un comando vs la consulta
● Usar excepciones en lugar de codigos de error
● No repetirnos a nosotros mismos DRY
● Evitar uso del try catch ( confinar esto en metodos descriptivos)
● No retorne nulls ( ejemplo lista vacia en vez de null)
● Tener efectos colaterales
● COMENTARIOS
● Que preferirias ver?
● TODO
Sirve solo si se revisan periódicamente
● FORMATEO
● Que los métodos no tengan más de 10 o 20 líneas o que quepa en la pantalla
del monitor.
● Horizontalmente que se vea en la pantalla
● Utilizar espacios en los parámetros
● Cantidad de espacios o tabs al identar
● Considerar la posición de las llaves
● Todas las reglas deben estar claras para todo el equipo
ABSTRACCIONES
● Encapsulamiento
● DTO
● Active Record . ( 1-1 con tablas relacionales)
● Excepciones chequeadas vs no chequeadas. Preferir las no chequeadas
CODE SMELL
● Duplicar código
● Extract Metod
● Codigo repetido en clases hermanas. Solucion herencia o composicion
● Cada vez que duplicamos estamos perdiendo la posibilidad de abstraccion
● Ojo con el copiar y pegar,
● switch (if/else)
● Patrones utiles, Template method, Stratety
CLASE LARGA
● Recordar el Single Responsability
● Acudir a tecnicas como composicion
MUCHOS PARAMETROS
● Maximo 2 o 3
● Revisar que los parametros no sean resultados de la ejecucion de otros
metodos.
● No pasar valores de otro objeto. Es preferible pasar el objeto completo o pasar la
logica al otro objeto
OBJETO ENVIDIOSO
● Es preferible tener las operaciones juntas con los atributos que manipulan
OBSESION PRIMITIVA
● Faciles de manipular
● Ejemplo las monedas, (valor y tipo de moneda por separado). Ejemplo pasarlo a
precio
CAMPO TEMPORARIO
● Son campos que no necesitan ser inicializados desde el comienzo
● Mover estos valores a otra clase.
REFACTOR
● Tener en cuenta la cobertura. Los ides ayudan
● Renombrar una variable. Identificar el alcance. Preferible variables locales y no
[Link] olvidar hacer las pruebas de nuevo
● Constantes. Identificar valores susceptibles de ser contantes
● Colecciones al encapsularlas hay que devolver una copia y reemplazar el set por add y
remove
● Condicionales anidados. Reducir el nivel de anidamiento
● SALIDA PREMATURA DE BUCLES - Utilizar breaks para reemplazar las banderas