notación húngara

La notación húngara es una convención de nomenclatura de identificadores en programación informática en la que el nombre de una variable o función indica su propósito o tipo, o, en algunos dialectos, su tipo . La notación húngara original utiliza únicamente el propósito o tipo en su convención de nomenclatura y a veces se la denomina notación húngara para aplicaciones , ya que se popularizó en la división de aplicaciones de Microsoft durante el desarrollo de las aplicaciones de Microsoft Office . Cuando la división de Microsoft Windows adoptó esta convención de nomenclatura, la basó en el tipo de dato real, y esta convención se extendió ampliamente a través de la API de Windows ; a esta se la conoce a veces como notación húngara de sistemas .

La notación húngara se diseñó para ser independiente del lenguaje y tuvo su primer uso importante con el lenguaje de programación BCPL . Dado que BCPL no tiene tipos de datos aparte de la palabra máquina , el propio lenguaje no ayuda al programador a recordar los tipos de las variables. La notación húngara busca solucionar esto proporcionando al programador información explícita sobre el tipo de dato de cada variable.

En la notación húngara, el nombre de una variable comienza con un grupo de letras minúsculas que sirven como mnemónicos para el tipo o propósito de dicha variable, seguido del nombre que el programador haya elegido; esta última parte a veces se denomina nombre dado . El primer carácter del nombre dado puede escribirse en mayúscula para diferenciarlo de los indicadores de tipo (véase también CamelCase ). En caso contrario, el uso de mayúsculas o minúsculas de este carácter indica el ámbito.

La notación húngara original fue inventada por Charles Simonyi , un programador que trabajó en Xerox PARC aproximadamente entre 1972 y 1981, y que más tarde se convirtió en arquitecto jefe de Microsoft . El nombre de la notación hace referencia a la nación de origen de Simonyi y también, según Andy Hertzfeld , porque hacía que los programas "parecieran escritos en algún idioma extranjero inescrutable". ^{[ 2 ]} Los nombres de las personas húngaras están "invertidos" en comparación con la mayoría de los demás nombres europeos; el apellido precede al nombre de pila . Por ejemplo, el nombre anglicizado "Charles Simonyi" en húngaro era originalmente "Simonyi Károly". De la misma manera, el nombre del tipo precede al "nombre de pila" en la notación húngara. El estilo de nomenclatura similar de Smalltalk "type last" (por ejemplo, aPoint y lastPoint) era común en Xerox PARC durante la etapa de Simonyi allí.

El artículo de Simonyi sobre la notación hacía referencia a los prefijos utilizados para indicar el "tipo" de información almacenada. ^{[ 3 ] [ 4 ]} Su propuesta se centraba principalmente en decorar los nombres de los identificadores en función de la información semántica de lo que almacenan (es decir, el propósito de la variable ). La notación de Simonyi llegó a conocerse como Húngaro de Aplicaciones, ya que la convención se utilizaba en la división de aplicaciones de Microsoft. El Húngaro de Sistemas se desarrolló posteriormente en el equipo de desarrollo de Microsoft Windows . El Húngaro de Aplicaciones no es del todo distinto de lo que se conoció como Húngaro de Sistemas, ya que algunos de los prefijos sugeridos por Simonyi contienen poca o ninguna información semántica (véanse los ejemplos a continuación). ^{[ 4 ]}

La diferencia entre la notación de sistemas y la notación de aplicaciones radica en la finalidad de los prefijos.

En la notación húngara de sistemas, el prefijo codifica el tipo de dato real de la variable. Por ejemplo:

• lAccountNum : la variable es un número entero largo ( "l");
• arru8NumberList : la variable es una matriz de enteros sin signo de 8 bits ( "arru8");
• bReadLine(bPort,&arru8NumberList) : función con un código de retorno de valor de byte.
• strName : La variable representa una cadena ( "str") que contiene el nombre, pero no especifica cómo se implementa esa cadena.

La notación húngara de Apps se esfuerza por codificar el tipo de dato lógico en lugar del tipo de dato físico; de esta manera, da una pista sobre cuál es el propósito de la variable o qué representa.

• rwPosition : la variable representa una fila ( "rw");
• usName : la variable representa una cadena no segura ( "us"), que necesita ser "sanitizada" antes de ser utilizada (por ejemplo, consulte inyección de código y secuencias de comandos entre sitios para ver ejemplos de ataques que pueden ser causados ​​por el uso de entradas de usuario sin procesar).
• szName : la variable es una cadena terminada en nulo ( "sz"); este fue uno de los prefijos sugeridos originalmente por Simonyi.

La mayoría, aunque no todos, de los prefijos propuestos por Simonyi son de naturaleza semántica. Para la mentalidad moderna, algunos prefijos parecen representar tipos de datos físicos, como szlas cadenas de caracteres. Sin embargo, estos prefijos seguían siendo semánticos, ya que Simonyi concibió la notación húngara para lenguajes cuyos sistemas de tipos no podían distinguir algunos tipos de datos que los lenguajes modernos dan por sentados.

Los siguientes son ejemplos del artículo original: ^{[ 3 ]}

• pXes un puntero a otro tipo X ; esto contiene muy poca información semántica.
• ddY es un prefijo que indica la diferencia entre dos valores; por ejemplo, dY podría representar una distancia a lo largo del eje Y de un gráfico, mientras que una variable llamada simplemente y podría ser una posición absoluta. Esto es puramente semántico.
• szes una cadena terminada en nulo. En C, esto contiene cierta información semántica porque no está claro si una variable de tipo char* es un puntero a un solo carácter, una matriz de caracteres o una cadena terminada en nulo.
• wMarca una variable que es una palabra. Esto no contiene prácticamente ninguna información semántica y probablemente se consideraría húngaro de sistemas.
• bEl prefijo `w` indica un byte, que, a diferencia de `w`, podría tener información semántica, ya que en C el único tipo de dato del tamaño de un byte es ` char` , por lo que a veces se utiliza para almacenar valores numéricos. Este prefijo podría aclarar la ambigüedad sobre si la variable contiene un valor que debe tratarse como un carácter o un número.

Si bien la notación siempre utiliza letras minúsculas iniciales como mnemotecnia, no prescribe las mnemotecnias en sí. Existen varias convenciones ampliamente utilizadas (véanse los ejemplos a continuación), pero se puede usar cualquier conjunto de letras, siempre que sean coherentes dentro de un cuerpo de código determinado.

Es posible que el código que utiliza la notación húngara de aplicaciones contenga a veces notación húngara de sistemas al describir variables que se definen únicamente en términos de su tipo.

En algunos lenguajes de programación, una notación similar, ahora llamada sigilos, está integrada en el lenguaje y es impuesta por el compilador . Por ejemplo, en algunas versiones de BASIC , name$se nombra una cadena y count%se nombra un entero . La principal diferencia entre la notación húngara y los sigilos es que estos últimos declaran el tipo de la variable en el lenguaje, mientras que la notación húngara es simplemente un esquema de nomenclatura que no afecta la interpretación del código del programa por parte de la máquina.

• bBusy : Booleano
• chInitial : carácter
• cApples : recuento de artículos
• dwLightYears : palabra doble (Sistemas)
• fBusy : bandera (o flotador )
• nSize : entero (Sistemas) o contador (Aplicaciones)
• iSize : entero (Sistemas) o índice (Aplicaciones)
• fpPrice : punto flotante
• decPrice : decimal
• dbPi : doble (Sistemas)
• pFoo : puntero
• rgStudents : matriz o rango
• szLastName : cadena terminada en nulo
• u16Identifier : entero sin signo de 16 bits (Systems)
• u32Identifier : entero sin signo de 32 bits (Systems)
• stTime : estructura del tiempo del reloj
• fnFunction : nombre de la función

Los mnemónicos para punteros y matrices , que no son tipos de datos reales, suelen ir seguidos del tipo del elemento de datos en sí:

• pszOwner : puntero a cadena terminada en nulo
• rgfpBalances : matriz de valores de punto flotante
• aulColors : matriz de enteros largos sin signo (Sistemas)

Si bien la notación húngara puede aplicarse a cualquier lenguaje y entorno de programación, Microsoft la adoptó ampliamente para su uso con el lenguaje C, en particular para Microsoft Windows , y su uso sigue estando mayoritariamente restringido a ese ámbito. En concreto, Charles Petzold difundió ampliamente el uso de la notación húngara en el libro Programming Windows , la obra original (y para muchos lectores, la definitiva) sobre programación de API de Windows . Por lo tanto, muchas construcciones comunes de la notación húngara son específicas de Windows.

• Para los programadores que aprendieron programación de Windows en C, probablemente los ejemplos más memorables sean el wParamparámetro (tamaño de palabra) y lParamel parámetro (entero largo) para la función WindowProc ().
• hwndFoo : identificador de una ventana
• lpszBar : puntero largo a una cadena terminada en nulo

En C++, la notación a veces se extiende para incluir el ámbito de una variable, opcionalmente separada por un guion bajo. ^{[ 5 ] [ 6 ]} Esta convención se utilizó ampliamente en la biblioteca de clases de la Fundación Microsoft . ^{[ 7 ]} A menudo también se utiliza sin la especificación de tipo húngara:

• g_nWheels : miembro de un espacio de nombres global, entero
• m_nWheels : miembro de una estructura/clase, entero
• m_wheels, _wheels : miembro de una estructura/clase
• s_wheels : miembro estático de una clase
• c_wheels : miembro estático de una función

(Algunas de estas disposiciones se aplican únicamente al sistema húngaro).

Los partidarios argumentan que los beneficios de la notación húngara incluyen: ^{[ 3 ]}

• El tipo de símbolo se puede identificar por su nombre. Esto resulta útil al examinar el código fuera de un entorno de desarrollo integrado , como en una revisión de código o una impresión , o cuando la declaración del símbolo se encuentra en un archivo distinto al de su uso, como por ejemplo una función.  
• En un lenguaje que utiliza tipado dinámico o que no tiene tipado, las decoraciones que hacen referencia a tipos dejan de ser redundantes. En dichos lenguajes, las variables normalmente no se declaran como portadoras de un tipo de dato particular, por lo que la única pista sobre las operaciones que se pueden realizar con ellas son las indicaciones del programador, como el esquema de nomenclatura de variables, la documentación y los comentarios. Como se mencionó anteriormente, la notación húngara se expandió en un lenguaje de este tipo ( BCPL ).
• El formato de los nombres de las variables puede simplificar algunos aspectos de la refactorización del código (aunque puede hacer que otros sean más propensos a errores).
• En un bloque de código se pueden usar varias variables con semántica similar: dwWidth, iWidth, fWidth, dWidth.
• Los nombres de las variables pueden ser fáciles de recordar con solo conocer sus tipos.
• Esto da como resultado nombres de variables más consistentes.
• Al leer el código, se pueden detectar fácilmente conversiones de tipo inapropiadas y operaciones que utilizan tipos incompatibles.
• En programas complejos con muchos objetos globales (formularios VB/Delphi), usar una notación de prefijo básica puede facilitar la búsqueda del componente dentro del editor. Por ejemplo, al buscar la cadena, btnse podrían encontrar todos los objetos Button.
• Aplicar la notación húngara de una manera más restrictiva, como por ejemplo aplicándola solo a las variables miembro , ayuda a evitar conflictos de nombres .
• El código impreso resulta más claro para el lector en lo que respecta a tipos de datos, conversiones de tipo, asignaciones, truncamientos, etc.

La mayoría de los argumentos en contra de la notación húngara se refieren a la notación húngara de sistemas , no a la notación húngara de aplicaciones . Algunos problemas potenciales son:

• La notación húngara resulta redundante cuando el compilador realiza la comprobación de tipos. Los compiladores de lenguajes que ofrecen una comprobación de tipos estricta, como Pascal , garantizan automáticamente que el uso de una variable sea coherente con su tipo; las comprobaciones visuales son redundantes y están sujetas a errores humanos.
• La mayoría de los entornos de desarrollo integrados modernos muestran los tipos de variables bajo demanda y marcan automáticamente las operaciones que utilizan tipos incompatibles, lo que hace que la notación sea prácticamente obsoleta. En los lenguajes de estilo C, el tipo ya forma parte de la declaración de la variable, mientras que en otros lenguajes como Rust, el tipo se puede anotar explícitamente en la declaración.
• La notación húngara se vuelve confusa cuando se utiliza para representar varias propiedades, como en : un argumento , que es constante , y es una referencia que contiene el contenido de una columna de base de datos de tipo varchar (30) que forma parte de la clave primaria de la tabla . a_crszkvc30LastNameColLastName
• Esto puede generar inconsistencias al modificar o portar código. Si se cambia el tipo de una variable, la decoración del nombre de la variable será inconsistente con el nuevo tipo, o bien será necesario cambiar el nombre de la variable. Un ejemplo particularmente conocido es el tipo estándar WPARAM y el parámetro formal wParam que lo acompaña en muchas declaraciones de funciones del sistema Windows. La 'w' significa 'palabra', donde 'palabra' es el tamaño de palabra nativo de la arquitectura de hardware de la plataforma. Originalmente era un tipo de 16 bits en arquitecturas de palabra de 16 bits, pero se cambió a un tipo de 32 bits en arquitecturas de palabra de 32 bits, o a un tipo de 64 bits en arquitecturas de palabra de 64 bits en versiones posteriores del sistema operativo, conservando su nombre original (su verdadero tipo subyacente es UINT_PTR, es decir, un entero sin signo lo suficientemente grande como para contener un puntero). La dificultad semántica, y por ende la confusión e inconsistencia de los programadores entre plataformas, radica en la suposición de que 'w' representa una palabra de dos bytes y 16 bits en esos diferentes entornos.
• En la mayoría de los casos, conocer el uso de una variable implica conocer su tipo. Además, si se desconoce el uso de una variable, no se puede deducir a partir de su tipo.
• La notación húngara reduce las ventajas de usar editores de código que admiten la autocompletación de nombres de variables, ya que el programador tiene que introducir primero el especificador de tipo, lo que aumenta la probabilidad de que entre en conflicto con otras variables que cuando se utilizan otros esquemas de nomenclatura.
• Esto dificulta la lectura del código, al ocultar el propósito de la variable con prefijos de tipo y ámbito. ^{[ 8 ]}
• La información adicional sobre el tipo de dato puede no ser suficiente para reemplazar nombres más descriptivos. Por ejemplo, "base de datos" no le indica al lector qué es. "Nombre de la base de datos" podría ser un nombre más descriptivo.
• Cuando los nombres son suficientemente descriptivos, la información adicional sobre el tipo puede resultar redundante. Por ejemplo, firstName probablemente sea una cadena de texto. Por lo tanto, llamarlo sFirstName solo añade complejidad al código.
• Es más difícil recordar los nombres.
• Se pueden usar varias variables con semántica diferente en un bloque de código con nombres similares: dwTmp, iTmp, fTmp, dTmp .

• Robert Cecil Martin (contra la notación húngara y todas las demás formas de codificación):

  ... hoy en día, HN y otras formas de codificación de tipos son simplemente impedimentos. Dificultan el cambio de nombre o tipo de una variable, función, miembro o clase. Dificultan la lectura del código. Y crean la posibilidad de que el sistema de codificación confunda al lector. ^{[ 9 ]}

• Linus Torvalds (contra Sistemas Húngaros):

  Codificar el tipo de una función en su nombre (la llamada notación húngara) es un error garrafal: el compilador conoce los tipos de todos modos y puede comprobarlos, y solo confunde al programador. ^{[ 10 ]}

• Steve McConnell (para Apps Hungarian):

  Aunque la convención de nomenclatura húngara ya no se usa ampliamente, la idea básica de estandarizar abreviaturas concisas y precisas sigue siendo valiosa. Los prefijos estandarizados permiten verificar los tipos con precisión cuando se utilizan tipos de datos abstractos que el compilador no necesariamente puede verificar. ^{[ 11 ]}

• Bjarne Stroustrup (contra Systems Hungría por C++):

  No, no recomiendo el método "húngaro". Considero que este método (que consiste en incorporar una versión abreviada de un tipo en el nombre de una variable) es una técnica útil en lenguajes sin tipado estático, pero completamente inadecuada para un lenguaje que admite programación genérica y programación orientada a objetos, ya que ambas enfatizan la selección de operaciones en función del tipo y los argumentos (conocidos por el lenguaje o por el entorno de ejecución). En este caso, "incorporar el tipo de un objeto en los nombres" simplemente complica y minimiza la abstracción. ^{[ 12 ]}

• Joel Spolsky (para Apps Hungarian):

  Si lees atentamente el artículo de Simonyi, a lo que se refería era al mismo tipo de convención de nomenclatura que usé en mi ejemplo anterior, donde decidimos que ussignificaba cadena insegura y ssignificaba cadena segura. Ambas son del tipo string. El compilador no te ayudará si asignas una a la otra e Intellisense [un sistema inteligente de autocompletado de código ] no te dirá nada . Pero son semánticamente diferentes. Deben interpretarse y tratarse de manera diferente, y se deberá llamar a algún tipo de función de conversión si asignas una a la otra o tendrás un error en tiempo de ejecución. Si tienes suerte. Todavía hay una enorme cantidad de valor en Apps Hungarian, ya que aumenta la colocación en el código, lo que hace que el código sea más fácil de leer, escribir, depurar y mantener, y, lo más importante, hace que el código incorrecto parezca incorrecto... (Systems Hungarian) fue un malentendido sutil pero completo de la intención y la práctica de Simonyi. ^{[ 4 ]}

• Las Directrices de Diseño de Microsoft ^{[ 13 ]} desaconsejan a los desarrolladores el uso de la notación húngara de sistemas al elegir nombres para los elementos en las bibliotecas de clases de .NET, aunque era común en plataformas de desarrollo anteriores de Microsoft como Visual Basic 6 y versiones anteriores. Estas Directrices de Diseño no especifican las convenciones de nomenclatura para las variables locales dentro de las funciones.

• Convención de nomenclatura de Leszynski , una variante del húngaro para el desarrollo de bases de datos.
• Camel case , otra convención de nomenclatura muy extendida
• Notación polaca , un concepto no relacionado con un nombre similar.

• Metaprogramación: Un método de producción de software. Charles Simonyi, diciembre de 1976 (Tesis doctoral).
• húngaronotación - ahora es mi turno  :) – Blog de Larry Osterman
• Notación húngara (MSDN)
• Versión HTML del artículo de Doug Klunder , Diseño de software de bucle inactivo, archivado el 9 de mayo de 2023.
• Convenciones de nomenclatura de RVBA
• Convenciones de estilo de codificación (MSDN)