Clean Code – Código
Limpio
Cristián Santelices Castillo
¿Qué es Clean Code o Código
Limpio?
• Filosofía de desarrollo de software que busca escribir
código legible, claro, mantenible y fácil de
entender para otros desarrolladores (y para uno mismo
en el futuro), no solo que funcione, centrándose en
principios como nombres descriptivos, funciones
pequeñas que hacen una sola cosa, reutilización de
código y eliminación de duplicaciones, para mejorar la
calidad y sostenibilidad del software a largo plazo.
Acerca del autor
• Robert Cecil Martin (conocido cómo Uncle Bob) , es un
estadounidense Ingeniero de software y autor de libros
de tecnología. El es coautor del manifiesto Ágil.
Concepto clave
• No basta con que el código funcione; debe ser fácil de
leer y mantener. "Escribes código para humanos, no
solo para máquinas".
Uso de Nombres con Significado
• El nombre de una variable, función o clase debe decir
por qué existe, qué hace y cómo se usa.
• Evita nombres genéricos: data, info, list.
• Usa nombres pronunciables y buscables: Es mejor
diasParaElVencimiento que d1.
• Clases y Objetos: Deben ser sustantivos (User,
Account).
• Métodos: Deben empezar con verbos (saveUser,
calculateTotal).
Funciones (Pequeñas y Simples)
• Las funciones(métodos) son la primera línea de
organización en cualquier programa.
• Regla de oro: Deben ser extremadamente pequeñas
(raras veces más de 20 líneas).Haz una sola cosa (SRP):
Una función debe tener una única responsabilidad.
• Niveles de abstracción: Todo el código dentro de una
función debe estar al mismo nivel de detalle.
Argumentos de Funciones (métodos)
• Menos, es más. La carga cognitiva aumenta con cada
parámetro.
• Ideal: 0 argumentos.
• Aceptable: 1 o 2 argumentos.
• Evitar: 3 o más argumentos (si llegas a este punto,
considera agruparlos en un objeto/clase).
• Prohibido: Pasar "flags" booleanas como argumentos
(esto indica que la función hace más de una cosa).
Comentarios (El mal necesario)
• "Los comentarios no compensan el código malo".
• Código auto explicativo: Si necesitas un comentario
para explicar qué hace el código, es mejor refactorizar
el código para que sea claro.
• Comentarios buenos: Notas legales, advertencias
sobre consecuencias, o explicaciones de intención de
negocio compleja.
• Comentarios malos: Ruido, comentarios redundantes,
o código comentado.
Formato y Estilo
El formato es comunicación. La legibilidad afecta la
mantenibilidad a largo plazo.
• Densidad vertical: Las líneas de código relacionadas
deben estar juntas; las distintas, separadas por
espacios.
• Distancia vertical: Las variables deben declararse
cerca de donde se usan. Las funciones relacionadas
deben estar cerca una de otra.
• Orden: El código debe leerse como un artículo de
periódico, de arriba hacia abajo (lo más importante
primero).
Objetos v/s Estructuras de Datos
Existe una diferencia fundamental entre ambos.
• Objetos: Esconden sus datos tras abstracciones y
exponen funciones (comportamiento).
• Estructuras de Datos: Exponen sus datos y no tienen
funciones significativas.
• Ley de Demeter: Un módulo no debe conocer los
detalles internos de los objetos que manipula. "Habla
con tus amigos, no con extraños".
Manejo de Errores
El manejo de errores es importante, pero si oscurece la
lógica, está mal hecho.
• Usa excepciones, no códigos de retorno: Esto
limpia la lógica principal del negocio.
• No devuelvas null: Obligas al receptor a verificarlo
constantemente. Devuelve una lista vacía o un objeto
especial.
• No pases null: Evita errores de puntero nulo en
tiempo de ejecución.
Pruebas Unitarias (TestDrivenDeveloper)
El código limpio no existe sin pruebas que aseguren que
el programa no se rompa al cambiarlo.
• Dentro de las 3 leyes del TDD: No escribas código de
producción sin una prueba que falle primero.
• Reglas F.I.R.S.T. de las pruebas:
• Fast (Rápidas)
• Independent (Independientes)
• Repeatable (Repetibles)
• Self-Validating (Auto-evaluables)
• Timely (Oportunas)
Conclusión y Regla del Boy Scout
El camino hacia la excelencia técnica es constante.
• La Regla del Boy Scout: "Deja el código un poco más
limpio de como lo encontraste".
• Refactorización: El código limpio es un proceso
iterativo, no un evento único.
• Calidad sobre rapidez: Escribir código sucio para ir
rápido solo te frenará a largo plazo.
FIN