El otro día leí en un foro de programación una respuesta muy buena a una pregunta que muchos desarrolladores y programadores se hacen, especialmente cuando están empezando a programar, y he decidido compartirlo aquí en forma de post: 6 cosas que indican que tu código es bueno.Todo parte de una pregunta publicada por un forero que se declara programador por hobby que había aprendido en su día a desarrollar usando VBA para hacer que sus excel funcionaran más rápidamente. La pregunta que plantea es la siguiente:"Soy un programador por hobby (empecé con VBA para hacer excel más rápido) y he estado trabajando con VB.NET / C#.NET y ahora estoy aprendiendo ADO.NET. Este es mi primer post y pido disculpas por la naturaleza subjetiva de la pregunta.Una de las facetas de la programación que siempre me ha frustrado es saber cómo es el código considerado bueno, a que se asemeja. Yo no soy profesional así que no puedo comparar mi código con otros. ¿Qué hace que un programador sea mejor que otro? Es por alguna de las siguientes razones:
- ¿Tienen un mejor entendimiento de los objetos / las clases / los métodos en un lenguaje de programación dad0?
- ¿Sus programas de software son más eficientes?
- ¿Es el diseño de sus aplicaciones mucho mejor en términos de mejor documentación, mejor elección de nomenclaturas para las funciones, etc...?
Dicho de otra forma, si me sentase a analizar el código de un programador o desarrollador profesional ¿Qué es lo primero que me llamaría la atención de su código en comparación con el mío? Por ejemplo, yo leo libros del estilo'Professional ASP.NET' de Wrox press. ¿Son los ejemplos de código en dichos libros de 'clase mundial' ¿Es eso el máximo exponente? ¿Los más grandes programadores verían ese código y pensarían que es bueno?"Ante tal pregunta la respuesta con más votos positivos del hilo es la siguiente:"La lista que aparece abajo no es una lista cerrada, pero estas son las 6 cosas que indican que tu código es bueno desde mi punto de vista para dar respuesta a tu pregunta.
- Un buen código está bien ordenado, bien organizado. Los datos y las operaciones en clases van bien encajadas. No hay dependencias externas entre clases. No tiene aspecto de código espagueti.
- Los buenos comentarios al código explican por qué se hacen las cosas y no lo que hacen las cosas. El código mismo ya explica lo que hace. La necesidad de comentar el código debe ser mínima.
- Un buen código usa unas convenciones de nomenclatura que transmiten significado, salvo cuando tenemos que nombrar objetos transitorios o pasajeros. El nombre de las cosas debe ser informativo sobre cuando y cómo usar el objeto.
- Un buen código está bien testado. Las pruebas sirven de especificaciones ejecutables del código y de ejemplo de sus usos.
- Un buen código no es "astuto". Hace las cosas de forma directa, transparente y obvia.
- Un buen código se desarrolla en unidades de computación pequeñas y fáciles de leer. Dichas unidades deben ser re-utilizables a lo largo de todo el código.
Aún no lo he leído, pero tengo en mente leer un libro sobre el tema, Clean Code de Robert C. Martin."Y así concluye su respuesta. Me parecen todos ellos muy buenos consejos y en especial me gusta el punto 5. Es tremendamente difícil escribir código que otros programadores puedan leer y mantener y editar fácilmente.
