18 de Noviembre, 2005

¿Cómo llamar a las variables?

Hace un par de días preguntaban en Slashdot sobre políticas desarrollando código en equipo, es decir, qué estándares, protocolos y normas se siguen para que el trabajo en grupo sea más óptimo (más al menos que mi código lo entiendo yo y ya vale).

Uno de los comentarios hablaba de notación húngara. Concretamente decía que una política es encadenar en el sótano a los desarrolladores que empleen dicha forma para llamar a las variables hasta que desistan en su actitud :).

La notación húngara consiste, a grandes rasgos, en incluir en el nombre de la variable características como su tipo o función:

zsUserName: una cadena de texto de C (acabada en cero).
bRed: un número de 8 bits (byte).
dwFlags: un número de 32 bits (double word).
hwndMainWindow: el manejador (handler) de la ventana principal.
hndlRowResult: el manejador de una fila del resultado de una consulta a una base de datos :P.

Esta notación la inventó hace unos cuantos años un programador de Xerox, que posteriormente fue arquitecto jefe en Microsoft (sea lo que sea eso). Que contrataran al tipo este es probablemente uno de los factores que hacen al API de Win32 tan poco utilizable.

Una de las críticas que se le hacen a esta notación es que resulta muy complicado trabajar en equipo. Probemos a interpretar la siguiente frase, como si se lo dijéramos al compañero de la mesa de al lado:

Oye, ¿plstFindInfo->ftCreationTime puede ser cero?

En efecto, se llena al monitor (o a tu compañero de trabajo) de perdigones al intentar pronunciar los nombres de las variables. Otra práctica de riesgo puede ser leer el código comiendo polvorones, ya que se acercan esas fechas tan entrañables.

Resumiendo: útil trabajando solo, pero poco práctico si depende de un equipo.

Yo admito ser un seguidor del modelo Camel Case (recomiendo leer sus supuestos orígenes, como el de Alto Keyboard :P), que le debe sonar a todo aquel que haya usado alguna vez un Wiki. Aunque al final todo depende del contexto, y suele ser buena idea que un equipo de pogramadores decidan una política sobre cómo escribir el código antes de empezar a trabajar.

Un ejemplo de dichas políticas puede ser style(9).

Anotación por Juan J. Martínez.

Los comentarios están cerrados: los comentarios se cierran automáticamente una vez pasados 30 días. Si quieres comentar algo acerca de la anotación, puedes hacerlo por e-mail.