Buenas prácticas
A los buenos desarrolladores les define la calidad de su código
Deberías programar siempre como si quien mantiene tu código fuera un psicópata que sabe donde vives
Principios
Principio de responsabilidad única
The Single Responsibility Principle (SRP) is a computer programming principle that states that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.
The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that
Una función debe hacer una sola cosa y hacerla bien. Las funciones deben hacer algo o responder algo, pero no ambas. Esto asegura que una función no tiene los llamados "efectos colaterales".
Se debe seguir el Principio de la mínima sorpresa: cualquier función o clase debe implementar las funcionalidades que otro programador pudiera esperar.
Algunos puntos que ayudan a cumplir este principio:
- Evitar pasar valores booleanos a una función: esto indica que la función tiene un IF-ELSE dentro para hacer más de una cosa.
- No devolver null.
- Las funciones no deberían tener más de 20 líneas.
- Evitar las estructuras de control "switch".
- El número ideal de parámetros de una función es cero. Si se tienen más de 3, seguramente se esté haciendo más de una cosa.
Elige nombres descriptivos
There are two hard problems in Computer Science: cache invalidation and naming things.
Establece nombres descriptivos de variables y funciones que puedan ayudar a cualquier compañero que lea tu código a entender el propósito de dicho elemento.
No reutilices variables.
No te preocupes por la logitud del nombre de una función. Si es descriptivo, ayudará a quien lo lea.
Haz tu código legible
Usa la tabulación y los espacios para facilitar la comprensión del código.
Una máquina lo entenderá, pero una mala indentación del código dificulta mucho su lectura.
Comentarios
The only truly good comment is the comment you found a way not to write.
- Pon comentarios cuando no has encontrado otra forma de esclarecer algo. No son necesarios los comentarios en Getters y Setters, por ejemplo.
- Elimina los comentarios obsoletos o inútiles.
- Es mejor poner un nombre significativo que no ponerlo y tener que añadir un comentario.
- El código debería entenderse sin comentarios. Si necesitas muchos, revisa tu código, deberías hacerlo más legible.
- Todo comentario que obligue a quien lo lea a mirar en otro módulo / clase habrá fallado miserablemente en su objetivo de comunicar algo y no merecerá la pena.
Don’t comment bad code, Rewrite it. — Brian W. Kernighan and P. J. Plaugher
Manten tu código simple
Un diseño se considera simple cuando:
- Todos los tests funcionan
- No tiene código duplicado (Famously known as DRY principle — Don’t repeat yourself )
- Expresa la intención del programador / objetivo del proyecto
- Minimiza el número de clases y métodos
Manejo de excepciones
Es mejor pasarse de precavido que sentirlo después. Añade bloques try/catch incluso cuando creas que no los necesitas.
Un buen manejo de excepciones hará que sea más fácil descubrir qué está pasando ya que sabrás con cada excepción lanzada qué bloque de código falla y por qué.
Cada excepción debe darte el suficiente contexto para determinar qué recurso y en qué método se localiza un error.
Logs
Los logs son el número 1 en recursos para debuguear tu código y monitorizar tu aplicación en producción.
Deberías escribir trazas de cualquier paso que tu usuario de, lógica compleja que se realice y errores o excepciones que puedan producirse.
También es importante dejar constancia de la fecha y hora cuando se graban esas trazas.
Variables
- Deben ser declaradas lo más cerca posible de donde vayan a ser utilizadas.
- Mantén tus variables privadas siempre que sea posible.
- Evita getters y setter que exponen todas las variables innecesariamente.
Principios SOLID
Regla del Boy Scout
Deja el campamento siempre más limpio que cuando llegaste.
En programación: Deja el código siempre mejor que como lo encontraste
Un ejemplo de acciones que mejoran el código:
- Elimina código y comentarios obsoleto
- Refactoriza el código mejorable
- Renombra métodos poco claros
- Añade bloques de control de errores donde no los haya
- Añade comentarios donde aporten valor