Notación húngara

Notación de nombres de identificadores de programación informática

La notación húngara es una convención de nombres de identificadores en programación informática en la que el nombre de una variable o función indica su intención o tipo, o en algunos dialectos, su tipo . La notación húngara original usa solo intención o tipo en su convención de nombres y a veces se la llama húngaro de aplicaciones , ya que se hizo popular en la división Microsoft Apps en el desarrollo de aplicaciones de Microsoft Office . Cuando la división Microsoft Windows adoptó la convención de nombres, la basaron en el tipo de datos real, y esta convención se difundió ampliamente a través de la API de Windows ; esto a veces se llama notación húngara de sistemas .

Simonyi : ...BCPL [tenía] un solo tipo que era una palabra de 16 bits... pero eso no importa.

Booch : A menos que continúes con la notación húngara.

Simonyi : Por supuesto... luego pasamos a los lenguajes tipificados... pero... nos fijamos en un nombre y te contaré mucho sobre él... ^[1]

La notación húngara fue diseñada para ser independiente del lenguaje y encontró su primer uso importante en el lenguaje de programación BCPL . Debido a que BCPL no tiene otros tipos de datos que la palabra de máquina , nada en el lenguaje en sí ayuda a un programador a recordar los tipos de variables. La notación húngara tiene como objetivo remediar esto al proporcionar al programador un conocimiento explícito del tipo de datos de cada variable.

En la notación húngara, el nombre de una variable comienza con un grupo de letras minúsculas que son mnemotécnicas para el tipo o propósito de esa variable, seguido por el nombre que el programador haya elegido; esta última parte a veces se distingue como el nombre de pila . El primer carácter del nombre de pila se puede escribir en mayúscula para separarlo de los indicadores de tipo (consulte también CamelCase ). De lo contrario, el uso de mayúsculas y minúsculas de este carácter denota el alcance.

Historia

La notación húngara original fue inventada por Charles Simonyi , un programador que trabajó en Xerox PARC entre 1972 y 1981, y que más tarde se convirtió en arquitecto jefe de Microsoft . El nombre de la notación es una 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 los húngaros están "invertidos" en comparación con la mayoría de los otros nombres europeos; el apellido precede al nombre de pila . Por ejemplo, el nombre anglicanizado "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 denominación similar de "último tipo" de Smalltalk (por ejemplo, aPoint y lastPoint) era común en Xerox PARC durante el mandato de Simonyi allí. ^{[ cita requerida ]}

El artículo de Simonyi sobre la notación se refería a los prefijos utilizados para indicar el "tipo" de información que se almacenaba. ^{[3] [4]} Su propuesta se centraba principalmente en decorar los nombres de los identificadores basándose en la información semántica de lo que almacenan (en otras palabras, el propósito de la variable ). La notación de Simonyi pasó a llamarse húngaro de aplicaciones, ya que la convención se utilizó en la división de aplicaciones de Microsoft. El húngaro de sistemas se desarrolló más tarde en el equipo de desarrollo de Microsoft Windows . El húngaro de aplicaciones no es completamente 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 (consulte los ejemplos a continuación). ^[4]

Sistemas húngaros vs. Aplicaciones húngaras

Donde la notación de sistemas y la notación de aplicaciones difieren es en el propósito de los prefijos.

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

• lAccountNum : variable es un entero largo ( "l");
• arru8NumberList : variable es una matriz de enteros de 8 bits sin signo ( "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 intenta codificar el tipo de datos lógicos en lugar del tipo de datos físicos; de esta manera, da una pista sobre cuál es el propósito de la variable o qué representa.

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

La mayoría de los prefijos que sugirió Simonyi, aunque no todos, son de naturaleza semántica. Para los ojos modernos, algunos prefijos parecen representar tipos de datos físicos, como szcadenas. Sin embargo, esos prefijos seguían siendo semánticos, ya que Simonyi pretendía que la notación húngara fuera para idiomas cuyos sistemas de tipos no podían distinguir algunos tipos de datos que los idiomas modernos dan por sentados.

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

• pXes un puntero a otro tipo X ; contiene muy poca información semántica.
• des un prefijo que significa 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 y podría ser una posición absoluta. Esto es de naturaleza completamente semántica.
• szes una cadena terminada en cero o nula. 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 cero.
• wMarca una variable que es una palabra. Esta no contiene prácticamente ninguna información semántica y probablemente se consideraría húngaro de sistemas.
• bmarca un byte, que a diferencia de w puede tener información semántica, porque en C el único tipo de datos de tamaño byte es char , por lo que a veces se utilizan para contener valores numéricos. Este prefijo puede 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 (ver ejemplos a continuación), pero se puede utilizar 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 a veces contenga húngaro de sistemas al describir variables que se definen únicamente en términos de su tipo.

Relación con los sigilos

En algunos lenguajes de programación, una notación similar llamada sigilos está incorporada al lenguaje y es aplicada por el compilador. Por ejemplo, en algunas formas de BASIC , name$nombra una cadena y count%nombra un entero . La principal diferencia entre la notación húngara y los sigilos es que los sigilos declaran el tipo de la variable en el lenguaje, mientras que la notación húngara es puramente un esquema de nombres sin efecto en la interpretación de la máquina del texto del programa.

Ejemplos

• bBusy : booleano
• chInitial : carácter
• cApples :conteo de artículos
• dwLightYears : palabra doble (sistemas)
• fBusy : bandera (o flotador )
• nSize : entero (sistemas) o conteo (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 cero
• u16Identifier: entero  de 16 bits sin signo (sistemas)
• u32Identifier: entero  de 32 bits sin signo (sistemas)
• 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 cero
• rgfpBalances : matriz de valores de punto flotante
• aulColors : matriz de valores largos sin signo (sistemas)

Aunque la notación húngara se puede aplicar 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 limitado en gran medida a esa área. En particular, el uso de la notación húngara fue ampliamente difundido por Charles Petzold en "Programming Windows" , el libro original (y para muchos lectores, el definitivo) sobre programación de API de Windows . Por lo tanto, muchas construcciones de notación húngara que se ven comúnmente son específicas de Windows:

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

La notación a veces se extiende en C++ para incluir el alcance de una variable, opcionalmente separada por un guión bajo. ^{[5] [6]} Esta extensión también se usa a menudo 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

En el código JavaScript que utiliza jQuery , $a menudo se utiliza un prefijo para indicar que una variable contiene un objeto jQuery (en lugar de un objeto DOM simple o algún otro valor). ^[7]

Ventajas

(Algunas de estas opciones se aplican únicamente a los sistemas húngaros).

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

• El tipo de símbolo se puede ver a partir de su nombre. Esto resulta útil cuando se observa 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 otro archivo desde el punto de uso, como una función.
• En un lenguaje que utiliza tipado dinámico o que no tiene tipado, las decoraciones que hacen referencia a los tipos dejan de ser redundantes. En dichos lenguajes, las variables normalmente no se declaran como si contuvieran un tipo particular de datos, por lo que la única pista sobre qué operaciones se pueden realizar con ellas son las sugerencias que da el programador, como un esquema de nombres de variables, documentación y comentarios. Como se mencionó anteriormente, la notación húngara se expandió en dichos lenguajes ( BCPL ).
• El formato de los nombres de variables puede simplificar algunos aspectos de la refactorización del código (mientras que hace que otros aspectos sean más propensos a errores).
• Se pueden utilizar varias variables con semántica similar en un bloque de código: dwWidth, iWidth, fWidth, dWidth.
• Los nombres de las variables pueden ser fáciles de recordar con solo conocer sus tipos.
• Esto conduce a nombres de variables más consistentes.
• Las conversiones de tipos inadecuadas y las operaciones que utilizan tipos incompatibles se pueden detectar fácilmente al leer el código.
• En programas complejos con muchos objetos globales (formularios VB/Delphi), tener una notación de prefijo básica puede facilitar la tarea de encontrar el componente dentro del editor. Por ejemplo, al buscar la cadena, btnse pueden encontrar todos los objetos Button.
• La aplicación de la notación húngara de una manera más restringida, por ejemplo aplicándola solo a las variables miembro , ayuda a evitar colisiones de nombres .
• El código impreso es más claro para el lector en el caso de tipos de datos, conversiones de tipos, asignaciones, truncamientos, etc.

Desventajas

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 ^{[ cita requerida ]} . Algunos problemas potenciales son:

• La notación húngara es redundante cuando la comprobación de tipos la realiza el compilador. Los compiladores para lenguajes que ofrecen una comprobación de tipos estricta, como Pascal , garantizan que el uso de una variable sea coherente con su tipo de forma automática; las comprobaciones a simple vista son redundantes y están sujetas a errores humanos.
• La mayoría de los entornos de desarrollo integrados modernos muestran tipos de variables a pedido y marcan automáticamente las operaciones que utilizan tipos incompatibles, lo que hace que la notación quede en gran medida obsoleta.
• La notación húngara se vuelve confusa cuando se utiliza para representar varias propiedades, como en a_crszkvc30LastNameCol: un argumento de referencia constante , que contiene el contenido de una columna de base de datos de tipo varchar (30) que es parte de la clave principal de la tabla . LastName
• Esto puede generar inconsistencias cuando se modifica o traslada el código. Si se cambia el tipo de una variable, la decoración del nombre de la variable será incoherente con el nuevo tipo, o bien se debe 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 de Windows. La 'w' significa 'word', donde 'word' 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 palabras de 16 bits, pero se cambió a 32 bits en arquitecturas de palabras de 32 bits, o a un tipo de 64 bits en arquitecturas de palabras de 64 bits en versiones posteriores del sistema operativo, manteniendo 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 impedancia semántica, y por ende la confusión y la inconsistencia del programador de una plataforma a otra, se basa en el supuesto de que "w" representa una palabra de dos bytes y 16 bits en esos diferentes entornos.
• La mayoría de las veces, conocer el uso de una variable implica conocer su tipo. Además, si no se conoce el uso de una variable, no se puede deducir su tipo.
• La notación húngara reduce los beneficios de usar editores de código que admiten la finalización de nombres de variables, ya que el programador debe ingresar primero el especificador de tipo, que tiene más probabilidades de colisionar con otras variables que cuando se usan otros esquemas de nombres.
• Hace que el código sea menos legible al ofuscar el propósito de la variable con prefijos de tipo y alcance. ^[8]
• La información de tipo adicional no puede reemplazar de manera suficiente a nombres más descriptivos. Por ejemplo, sDatabase no le dice al lector qué es. databaseName podría ser un nombre más descriptivo.
• Cuando los nombres son lo suficientemente descriptivos, la información de tipo adicional puede ser redundante. Por ejemplo, lo más probable es que firstName sea una cadena. Por lo tanto, nombrarlo sFirstName solo agrega desorden al código.
• Es más difícil recordar los nombres.
• Se pueden utilizar múltiples variables con diferente semántica en un bloque de código con nombres similares: dwTmp, iTmp, fTmp, dTmp .
• Colocar caracteres identificadores de tipo de datos o de intención como prefijo del nombre de campo o variable subvierte la capacidad, en algunos entornos de programación, de saltar al nombre de un campo o variable, en orden alfabético, cuando el usuario comienza a escribir el nombre. FileMaker, ^[9] por ejemplo, es uno de esos entornos de programación. Al utilizar uno de estos entornos de programación, puede ser preferible agregar caracteres identificadores como sufijo a los nombres de campo o variable.

Opiniones notables

• Robert Cecil Martin (en contra de 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. Hacen que sea más difícil cambiar el nombre o el tipo de una variable, función, miembro o clase. Hacen que sea más difícil leer el código y crean la posibilidad de que el sistema de codificación confunda al lector. ^[10]

• Linus Torvalds (contra Systems Hungarian):

  Codificar el tipo de una función en el nombre (la llamada notación húngara) es perjudicial para la salud: el compilador conoce los tipos de todos modos y puede comprobarlos, y eso sólo confunde al programador. ^[11]

• Steve McConnell (para aplicaciones húngaras):

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

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

  No, no recomiendo el "húngaro". Considero que el "húngaro" (incorporar una versión abreviada de un tipo en el nombre de una variable) es una técnica que puede ser útil en lenguajes sin tipos, pero que es completamente inadecuada para un lenguaje que admita programación genérica y programación orientada a objetos, que enfatizan la selección de operaciones en función del tipo y los argumentos (conocidos por el lenguaje o por el soporte en tiempo de ejecución). En este caso, "compilar el tipo de un objeto en nombres" simplemente complica y minimiza la abstracción. ^[13]

• Joel Spolsky (para aplicaciones húngaras):

  Si lees el artículo de Simonyi con atención, lo que quería decir era el mismo tipo de convención de nombres que usé en mi ejemplo anterior, donde decidimos que ussignificaba cadena insegura y sque significaba cadena segura. Ambos son de tipo string. El compilador no te ayudará si asignas uno al otro e Intellisense [un sistema de finalización de código inteligente ] no te dirá nada. Pero son semánticamente diferentes. Deben interpretarse y tratarse de manera diferente y será necesario llamar a algún tipo de función de conversión si asignas uno al otro o tendrás un error de tiempo de ejecución. Si tienes suerte. El húngaro de aplicaciones sigue teniendo un enorme valor, 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 erróneo parezca erróneo... (Húngaro de sistemas) fue un malentendido sutil pero completo de la intención y la práctica de Simonyi. ^[4]

• Las pautas de diseño de Microsoft ^[14] desaconsejan a los desarrolladores el uso de la notación húngara de sistemas cuando eligen nombres para los elementos de las bibliotecas de clases de .NET, aunque era común en plataformas de desarrollo de Microsoft anteriores como Visual Basic 6 y anteriores. Estas pautas de diseño no se pronuncian sobre las convenciones de nombres para las variables locales dentro de las funciones.

Véase también

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

Referencias

1. "Historia oral de Charles Simonyi" (PDF) . Archive.computerhistory.org\accessdate=5 20 de agosto de 2018 . Archivado (PDF) desde el original el 10 de septiembre de 2015.
2. Rosenberg, Scott (1 de enero de 2007). "Todo lo que tú puedas hacer, yo lo puedo hacer". MIT Technology Review . Consultado el 21 de julio de 2022 .
3. Charles Simonyi (noviembre de 1999). "Notación húngara". Biblioteca MSDN . Microsoft Corp.
4. Spolsky, Joel (11 de mayo de 2005). "Cómo hacer que un código erróneo parezca erróneo". Joel on Software . Consultado el 13 de diciembre de 2005 .
5. "Mozilla Coding Style". Developer.mozilla.org . Archivado desde el original el 2 de diciembre de 2019. Consultado el 17 de marzo de 2015 .
6. "Directrices de estilo de codificación de Webkit". Webkit.org . Consultado el 17 de marzo de 2015 .
7. "¿Por qué una variable de JavaScript comienza con un signo de dólar?". Stack Overflow . Consultado el 12 de febrero de 2016 .
8. Jones, Derek M. (2009). El nuevo estándar C: un comentario cultural y económico (PDF) . Addison-Wesley. pág. 727. ISBN 978-0-201-70917-9. Archivado (PDF) del original el 1 de mayo de 2011.
9. "Cree una aplicación para cualquier tarea: FileMaker, una subsidiaria de Apple". Filemaker.com . Consultado el 5 de agosto de 2018 .
10. Martin, Robert Cecil (2008). Clean Code: A Handbook of Agile Software Craftsmanship [Código limpio: un manual de desarrollo ágil de software] . Redmond, WA: Prentice Hall PTR. ISBN 978-0-13-235088-4.
11. "Estilo de codificación del kernel de Linux". Documentación del kernel de Linux . Consultado el 9 de marzo de 2018 .
12. McConnell, Steve (2004). Código completo (2.ª edición). Redmond, WA: Microsoft Press . ISBN 0-7356-1967-0.
13. Stroustrup, Bjarne (2007). "Preguntas frecuentes sobre técnicas y estilos de C++ de Bjarne Stroustrup" . Consultado el 15 de febrero de 2015 .
14. "Directrices de diseño para el desarrollo de bibliotecas de clases: convenciones generales de nomenclatura" . Consultado el 3 de enero de 2008 .

Enlaces externos

• Metaprogramación: un método de producción de software Charles Simonyi, diciembre de 1976 (tesis doctoral)
• Notación húngara: ahora me toca a mí :) – Blog de Larry Osterman
• Notación húngara (MSDN)
• Versión HTML del artículo de Doug Klunder ^{[ enlace muerto permanente ]}
• Convenciones de nomenclatura de RVBA
• Convenciones de estilo de codificación (MSDN)