Summary of 'Clean code' by Robert C. Martin

clean_code.md

El código esta limpio si puede ser entendido fácilmente por todos en el equipo. Un código limpio puede ser leído y mejorado por un desarrollador que no sea su autor original. Con la comprensibilidad viene la legibilidad, la capacidad de cambio, la extensibilidad y la facilidad de mantenimiento.

---

Reglas generales

1. Siga las convenciones estándar.
2. Mantenlo simple y estúpido. Lo más simple siempre es mejor. Reduzca la complejidad tanto como sea posible.
3. Regla de los boy scouts. Deje el campamento más limpio de lo que lo encontró.
4. Siempre encuentre la causa raíz. Busque siempre la causa raíz de un problema.

Reglas de diseño

1. Mantenga los datos configurables en niveles altos.
2. Prefiera el polimorfismo a if / else o switch / case.
3. Código de múltiples subprocesos separado.
4. Evite la configuración excesiva.
5. Utilice inyección de dependencia.
6. Siga la ley de Demeter. Una clase solo debe conocer sus dependencias directas.

Consejos de comprensibilidad

1. Sea consistente. Si hace algo de cierta manera, haga todas las cosas de la misma forma.
2. Utilice variables explicativas.
3. Encapsule las condiciones de contorno. Las condiciones de contorno son difíciles de seguir. Ponga el procesamiento de ellos en un solo lugar.
4. Prefiera los objetos de valor dedicados al tipo primitivo.
5. Evite la dependencia lógica. No escriba métodos que funcionen correctamente dependiendo de otra cosa en la misma clase.
6. Evite los condicionales negativos.

Reglas de nombres

1. Utilice nombres descriptivos e inequívocos.
2. Haga una distinción significativa.
3. Utilice nombres pronunciables.
4. Utilice nombres que se puedan buscar.
5. Reemplaze los números mágicos por constantes nombradas.
6. Evite las codificaciones. No agregue prefijos ni escriba información.

Reglas de funciones

1. Cortas.
2. Hacen una cosa.
3. Usar nombres descriptivos.
4. Prefiera menos argumentos.
5. No tener efectos secundarios.
6. No use argumentos bandera. Dividir el método en varios métodos independientes que se pueden llamar desde el cliente sin la bandera.

Reglas de comentarios

1. Siempre trate de explicarse con el código.
2. No seas redundante.
3. No agregue ruido obvio.
4. No use comentarios de llaves de cierre.
5. No comente el código. Simplemente elimínelo.
6. Úselo para explicar la intención.
7. Úselo para aclarar el código.
8. Úselo para advertir de consecuencias.

Estructura del código fuente

1. Separe los conceptos verticalmente.
2. El código relacionado debe aparecer verticalmente denso.
3. Declarar variables cercanas a su uso.
4. Las funciones dependientes deben estar cerca.
5. Las funciones similares deberían estar cerca.
6. Coloque las funciones en dirección descendente.
7. Mantenga las líneas cortas.
8. No use alineación horizontal.
9. Use espacios en blanco para asociar cosas relacionadas y disociar las relacionadas débilmente.
10. No rompa la identación.

Objetos y estructuras de datos

1. Oculte la estructura interna.
2. Prefiera las estructuras de datos.
3. Evite las estructuras híbridas (mitad objeto y mitad datos).
4. Debe ser pequeño.
5. Debe hacer una cosa.
6. Pequeño número de variables de instancia.
7. La clase base no debería saber nada sobre sus derivadas.
8. Es mejor tener muchas funciones que pasar un código a una función para seleccionar un comportamiento.
9. Prefiera los métodos no estáticos a los estáticos.

Tests | Pruebas

1. Una afirmación por prueba.
2. Legible.
3. Rápido.
4. Independiente.
5. Repetible.

Code smells | El código huele

1. Rigidez. El software es difícil de cambiar. Un pequeño cambio provoca una cascada de cambios posteriores.
2. Fragilidad. El software se rompe en muchos lugares debido a un solo cambio.
3. Inmovilidad. No puede reutilizar partes del código en otros proyectos debido a los riesgos involucrados y al gran esfuerzo.
4. Complejidad innecesaria.
5. Repetición innecesaria.
6. Opacidad. El código es difícil de entender.