¿Qué es el Clean Code?
No es solo un libro. Es una forma de vida, un llamado a dejar de escribir código como si fuéramos monos apurados tocando el teclado. Clean Code (o "Código Limpio", para los que les gusta el español) es ese libro escrito por Robert C. Martin (alias Uncle Bob), uno de los gurúes del desarrollo Agile y el tipo que nos regaló los principios SOLID. Si sos programador y no lo leíste, ¿en qué andás, my bro?
Imaginate
entrar a un código lleno de variables como x, temp,
o funciones llamadas hacerTodo().
Es como entrar a un departamento en Constitución a las 3 AM: nadie
quiere estar ahí o
, por lo menos nadie que quiera seguir conservado eso cerrado.
El Clean Code viene a salvarte de eso.
¿Por qué me debería importar?
Acá va la posta: el 90% del tiempo no estás escribiendo código nuevo, estás leyendo código viejo (el tuyo o el de otro). Y si ese código es un quilombo, cada vez que lo toques vas a sentir que estás descifrando jeroglíficos egipcios después de tres fernets.
El código limpio es como una casa bien construida:
No se cae (o al menos, no tan fácil).
Se puede agrandar sin que todo explote.
La gente quiere vivir ahí (o en este caso, trabajar en él).
¿Cómo reconocer un código limpio?
Según Uncle Bob, el código limpio tiene que ser:
Legible:
Que se lea como una novela, no como un contrato de
internet.
Sencillo:
Que haga una
cosa y
la haga bien (como un buen mate).
Minimalista:
Nada de repetir como loro. DRY (Don’t
Repeat Yourself),
viejo.
Intencional:
Que los nombres digan exactamente qué
hacen. Si tenés que adivinar, ya está mal.
Estructurado:
Que siga patrones sólidos (nunca mejor dicho, SOLID).
Probado:
Sin tests, tu código es como un auto sin frenos: eventualmente
se estrella.
Las preguntas que siempre te hiciste
1. ¿Qué hace que un nombre sea bueno?
Que no
necesite comentario.
Si tu variable se llama usr en
vez de user,
o calc() en
vez de calculateTotal(),
estás haciendo las cosas mal.
"Si necesitás un comentario para explicar el nombre, el nombre está mal."
2. ¿Cuándo una función es demasiado larga?
Cuando no entra en la pantalla sin scrollear, o peor: cuando la leés y te dan ganas de llorar. Para Uncle Bob, lo ideal son 3-5 líneas.
"Una función = una responsabilidad. Si hace más, partila como una pizza."
3. ¿Formatear el código es importante o es hinchapelotas?
El código mal indentado es como ir a una entrevista en ojotas: no da confianza. Un buen formato evita errores y hace que otros (o vos en 6 meses) no quieran prender fuego la oficina.
Usá linters (como ESLint o Prettier), pero no delegues todo a la máquina.
4. ¿Cuándo hay que borrar comentarios?
Cuando el código se explica solo. Los comentarios son como los parches: útiles en emergencias, pero si los usás todo el tiempo, algo huele mal.
"Si el código es confuso, arreglalo, no lo expliques con un comentario."
5. ¿Qué es el código muerto?
Todo eso que no se usa: funciones olvidadas, variables fantasma, imports que están ahí "por las dudas". Borralo. Menos es más.
6. ¿Por qué los efectos colaterales son malos?
Porque
son como invitar
a tu ex a una juntada con amigos: nunca
termina bien.
Si tu función saveUser() también
manda un mail, estás rompiendo las reglas del juego.
NO
se hace: saveUserAndSendEmail()
SI
se hace: saveUser() + sendEmail()
7. ¿Clean Code y tests van de la mano?
Sí, como el mate y la bombilla. Si no tenés tests, tu código es un castillo de naipes: un cambio mínimo y todo se derrumba.
