Nombres: ¿Cómo tienen que ser?
Significativos y pronunciables
¿Qué deben revelar los nombres?
La intención
¿Qué son “Searchable Names”?
- La longitud del nombre corresponde al tamaño de su alcance
- Si una variable o constante puede verse o usarse en varios lugares de un cuerpo de código, debe tener nombre fácil de buscar.
¿Qué características deben tener los nombres?
- pronunciables
- buscables
- para las clases, sustantivos
- para los métodos, verbos
- tener una palabra por concepto
- contexto significativo y reducido
Nombres: ¿Qué debemos evitar?
- desinformación
- codificación
- prefijos
- mapeo mental
- copiar palabras
Funciones: ¿Cómo deben ser?
- Pequeños
- Que hagan una sola cosa (Single Responsibility Principle)
- Un sólo nivel de abstracción por función.
- Argumentos: uno es bueno, cero es mejor.
- Respecto a switch y flags: preferible usar polimorfismo.
¿Qué es DRY?
Don’t Repeat Yourself:
- Si repetís código y necesitás a futuro cambiarlo, vas a tener que cambiarlo en cada instancia.
- Además, es una oportunidad para múltiples errores por omisión.
¿Qué es The Principle of Least Surprise?
Las acciones y resultados de un sistema deben seguir convenciones comunes y tener sentido para quienes los utilizan, minimizando las sorpresas y confusiones.
¿A qué se refiere la Boy Scout Rule?
Se refiere a la práctica de mejorar contínuamente el código fuente durante el desarrollo de software. Se basa en la idea de que los programadores deberían dejar el código en un estado mejor de lo que lo encontraron.
¿Cómo deben manejarse los errores?
Se deben usar excepciones en vez de códigos de error. También se debe evitar retornal Null.
Comentarios: ¿Qué comentarios son buenos?
Los legales, informativos, explicativos, clarificadores, previsores de consecuencias, recordatorios de trabajo, amplificadores de importancia.
Comentarios: ¿Qué comentarios son malos?
Redundantes, confusos, obligatorios, innecesarios, periódicos, código viejo, información no loca, etc.
Tests Unitarios: ¿Qué es FIRST?
Fast
Independent
Repeatable
Self-Validating
Timely
Tests Unitarios: ¿Qué cosas se deben hacer?
- siempre escribir casos de prueba aislados.
- probar una sola cosa en un sólo caso de prueba.
- usar un único assert por caso
- usar una convención de nombres para los casos de prueba.
- usar mensajes descriptivos para los métodos de assert.
- medir la cobertura de código para encontrar casos de prueba faltantes.
