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.