Breve resumen del libro “Clean Code – A Handbook for Agile Software Craftmanship”

Recientemente leí el libro “Clean Code – A Handbook for Agile Software Craftmanship” de Robert C. Martin y decidí compartir algunos apuntes interesantes sobre lo que el autor considera como buenas prácticas de programación.

Comentarios

  • Comentarios obsoletos: Los comentarios obsoletos son una fuente pródiga de errores pues dan una idea equivocada sobre la funcionalidad que tratan de describir. Si un comentario es especialmente difícil de mantener actualizado, es mejor eliminarlo y dejar que el código hable por si solo.
  • Comentarios redundantes: Los comentarios que reflejan lo obvio solo logran restar legibilidad.
  • Comentarios mal redactados: Los comentarios deben ser concisos. Las palabras y términos a utilizar se deben seleccionar cuidadosamente para evitar descripciones ambiguas.
  • Código comentado: Normalmente, nadie se atreve a borrar una sección de código comentado pues se asume que es de importancia para alguien más cuando en realidad es solo un remanente histórico de algún programador descuidado. El código comentado se debe eliminar sin contemplación!

Entorno

  • Facilidad de ejecución de los tests: Idealmente, todos los tests de un sistema se deben ejecutar con una única y simple acción, como por ejemplo, presionar un botón en el IDE (ideal) o ejecutar un comando en la consola.

Funciones

  • Cantidad de argumentos: La cantidad ideal de argumentos para una función es cero, seguido de uno, dos y tres. Una función nunca debería tener más de tres argumentos.
  • Argumentos como salida: Nunca modificar los argumentos (pasados por referencia) pues esto puede llevar a efectos colaterales imprevistos en el código cliente.
  • Argumentos booleanos: Nunca pasar un valor booleano como argumento de una función. Esto generalmente indica que la función tiene más de una responsabilidad.
  • NULL como valor de retorno: Es difícil interpretar el significado de NULL como retorno de una función. ¿Es un resultado vacío? ¿Es un error? ¿Es el valor esperado? Cuando ocurre un error en una función o método se debe arrojar una excepción, no retornar NULL o false.

Deja un comentario