El arte de nombrar (parte 2)

En la primera parte hice comentarios mayormente prácticos sobre problemas y sugerencias a la hora de dar nombres a variables, clases, funciones, etc. Ahora vengo a completar las ideas con otro punto de vista, pensando más en la elección de las palabras que en la forma de escribirlas o abreviarlas.

Estas reflexiones tienen dos orígenes: por un lado la introducción del clásico libro de patrones de diseño de "la Pandilla de 4", por el otro una mini-frustración personal que me agarra a veces dando clases.

De la intro del libro, sobre el primero de 4 elementos fundamentales de un patrón de diseño, su nombre:

"The pattern name is a handle we can use to describe a design problem, its solutions, and consequences in a word or two. Naming a pattern immediately increases our design vocabulary. It lets us design at a higher level of abstraction. Having a vocabulary for patterns lets us talk about them with our colleagues, in our documentation, and even to ourselves. It makes it easier to think about designs and to communicate them and their trade-offs to others. Finding good names has been one of the hardest parts of developing our catalog."

Aquí nos están tratando de hacer notar la importancia de contar con un buen "vocabulario". Cómo, cuando dicho vocabulario se populariza, con una palabra se puede describir todo un tipo de problema y los lineamientos generales de una solución. Cómo esto nos ayuda a documentar y comunicarnos con colegas con mucho menos esfuerzo. Cómo nos permite a nosotros mismos compactar las ideas y pensar con un mayor nivel de abstracción. Cómo un buen nombre puede decir muchísimo con muy poco. En este caso, no porque sea necesariamente autodescriptivo, sino por ser parte de un vocabulario específico de una disciplina.

Diría que este párrafo redujo muchísimo mi pseudo-desprecio por algunas publicaciones sobre ingeniería de software y metodologías ágiles. A veces veía que algunas no eran más que un obvio rejunte de cuestiones de sentido común básico, tan básico y común que no ameritaban un nombre propio, rimbombante, gracias al cual escribir posts, libros o papers sin decir nada esencialmente nuevo. Ahora veo que en muchos casos tiene su side-effect muy positivo, aunque no sea novedoso en absoluto, solo por el bien de establecer un vocabulario común, definir ciertos límites o agrupamientos, y ahorrarnos de ahora en más tantas repeticiones y discusiones innecesarias. Para que con un par de palabras ya todos sepamos dónde nos estamos moviendo y cuales son los principios básicos.

En este posts las metodologías ágiles la ligan de rebote (tomado de http://dilbert.com/strips/comic/2007-11-26/)

Por el otro lado, a veces me pasa todo lo contrario en clases. A veces alguien me hace una pregunta, y yo pienso que doy una respuesta simple y directa, pero al alumno no le dice nada. Digamos que estamos analizando una función en la que aparece una variable "foo" y no se ve por ningún lado su definición. Entonces un alumno pregunta: "profe, ¿de dónde sale esa variable?", o "¿no le falta definir esa variable?" o peor aún "¿esa es una variable global?"... Y yo digo, "No, lo que pasa es que esto es un método y ese es un atributo de la clase". Asumiendo que se sabe lo que se entiende por "método", "atributo" y "clase", no hay nada más que agregar, es claro y obvio. En realidad con solo decir "es un atributo" ya respondía a las tres preguntas.
Nota: en la bibliografía que usamos se usa "atributo" como "variable miembro", y "método" como "función miembro".

Pero si al alumno le da lo mismo "variable local" que "atributo", o le da lo mismo "función" [libre/global] que "método", porque no entendió la diferencia conceptual, o porque no detectó que esa diferencia era tan importante; entonces mi respuesta no sirve de absolutamente nada.

Y es un problema que me preocupa, porque estando la materia en el contexto de una "Ingeniería", es vital para la formación del alumno aprender a hablar con propiedad e identificar y distinguir claramente ciertos conceptos básicos. Es un ejemplo entre muchos, me pasa todo el tiempo en distintos contextos. Por dar otro rápido, en computación gráfica muchos mezclan "punto", "vértice", "fragmento", "pixel" como si todos fueran intercambiables. Y entonces ante un respuesta con esta mezcla, si el alumno no ve la importancia del vocabulario piensa "me mató por una palabrita", cuando en realidad mezclar, por ejemplo, "vértice" con "fragmento" implica no haber entendido nada de "rasterización", que es una de las unidades básicas de la materia.


Así que este segundo posts viene a abogar por del estudio y cultivo del vocabulario, del querer hablar con propiedad, y de elegir las palabras con cuidado, en pos de mejorar y optimizar la comunicación, y de evitar inútiles confusiones y repeticiones.

Entonces, elijan con cuidado también los nombres de cosas abstractas o de muy alto nivel, como sistemas, diseños, conceptos, etc. Nombres que tal vez no aparezcan explícitamente en el código, pero que son parte esencial del desarrollo y de su documentación. Y para poder hacerlo deberán leer mucho. Leer siempre enriquece el vocabulario. Leer por ejemplo libros/artículos sobre patrones e ingeniería de software, leer código de terceros, leer documentación de herramientas y bibliotecas, etc. Hasta leer ficción puede ayudar.