Durante años he podido comprobar que muchos de los compañeros(y yo) que desarrollan aplicaciones dejan los identificadores (nombres) por defecto que asignan automáticamente los entornos de desarrollo (IDE) a los distintos objetos y componentes.
También es muy habitual comenzar con un experimento, en el que no se presta atención a los nombres que se asignan a las variables, funciones y clases, que mas da, ¡es tan solo un experimento!. Lo malo que la mayoría de la veces el experimento se convierte en una aplicación real que durara años arrastrando ese “pequeño defecto” (los típicas MyObj, Test, Form1, Button1).
¿Donde está el problema?:
- por un lado el mantenimiento de un desarrollo suele ser mucho más largo que la fase de construcción, las personas que crean la pieza se van y otros tienen que retomar y descifrar el significado del código fuente.
No hay que olvidar que el código fuente es “la documentación más relevante de un desarrollo de software”
- y lo más importante, cuando escribimos el código estamos modelando nuestro software y esto precisa analizar, abstraer y pensar mucho, la decisión de un nombre de una clase es esencial para realizar el modelado, si pensamos bien el identificador seguro que estamos haciendo un buen diseño de la pieza en cuestión.
En el momento de poner un nombre, aunque sea a un objeto o método de lo más insignificante hay que pensar: ¿Que debe hacer?¿Cómo se relaciona con el mundo exterior?
Seguro que la práctica de pararnos a pensar en los nombres ayudaran que nuestro código sea más legible y el software de mayor calidad.
Cuanta razón tienes!!!!
correcto, aunque obvio
De todos modos, el que se vea libre de culpa que tire la primera piedra.
Si se comienza un proyecto en serio, y se estipulan una serie de convenciones de nomenclatura, no son esperables problemas como los que describes.
Pero, ¿a cuántos os ha pasado que habéis empezado una app, que en su origen era una chorrada, o una prueba de concepto, y que luego ha ido creciendo y creciendo, hasta alcanzar un tamaño que te quita las ganas de recomenzarlo todo para tener una nomenclatura mejor?
Por suerte, con los proyectos más serios no debería ocurrir; pienso que un equipo de trabajo debe tener definidas unas convenciones a las que ajustarse, y si es necesario revisarlas al inicio del proyecto. Antes de empezar a escribir código.
Estoy de acuerdo. No dar nombres apropiados es síntoma de no saber lo que estás haciendo y tiene repercusiones a todos los niveles. A veces es mejor gastar más tiempo en reflexionar sobre el nombre de una clase, método, función o variable que a su implementación.
Reflexión relacionada: Yo no soy muy partidario de escribir comentarios en el código, opino que un código que necesita comentarios es un código que no está claro. Siempre le digo lo mismo a mis alumnos, si sientes la necesidad de añadir un comentario para aclarar tu código, piensa si no conseguirías lo mismo dando un nombre más apropiado a alguna de las variables involucradas.