Notación húngara

Notación de denominación de identificadores (informática)

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 intención o tipo, o en algunos dialectos, su tipo . La notación húngara original utiliza sólo intención o tipo en su convención de nomenclatura y, a veces, se denomina Apps húngaras, ya que se hizo popular en la división Microsoft Apps en el desarrollo de aplicaciones de Microsoft Office . Cuando la división de Microsoft Windows adoptó la convención de nomenclatura, la basó en el tipo de datos real, y esta convención se difundió ampliamente a través de la API de Windows ; A esto a veces se le llama notación húngara de sistemas .

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

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

Simonyi : Por supuesto... también pasamos a los idiomas mecanografiados más tarde... Pero... mirábamos un nombre y les contaba exactamente mucho sobre eso... ^[1]

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

En notación húngara, el nombre de una variable comienza con un grupo de letras minúsculas que son mnemónicos para el tipo o propósito de esa variable, seguidas del nombre que haya elegido el programador; 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 (ver también CamelCase ). De lo contrario, el caso de este carácter denota 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 demás nombres europeos; el apellido precede al nombre de pila . Por ejemplo, el nombre inglés "Charles Simonyi" en húngaro era originalmente "Simonyi Károly". De la misma manera, el nombre del tipo precede al "nombre de pila" en notación húngara. El estilo similar de denominación de "tipo último" de Smalltalk (por ejemplo, aPoint y lastPoint) era común en Xerox PARC durante el mandato de Simonyi allí. ^{[ cita necesaria ]}

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 almacena. ^{[3] [4]} Su propuesta se refería en gran medida a 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 denominarse Aplicaciones húngaras, ya que la convención se utilizaba en la división de aplicaciones de Microsoft. Los sistemas húngaros se desarrollaron posteriormente en el equipo de desarrollo de Microsoft Windows . Apps Húngaro no es completamente distinto de lo que se conoció como Sistemas Húngaro, ya que algunos de los prefijos sugeridos por Simonyi contienen poca o ninguna información semántica (ver ejemplos a continuación). ^[4]

Sistemas húngaros versus aplicaciones húngaras

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

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

• lAccountNum : la variable es un número entero largo ( "l");
• arru8NumberList : la 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 de las aplicaciones se esfuerza por codificar el tipo de datos lógico en lugar del tipo de datos 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 insegura ( "us"), que debe "desinfectarse" antes de usarse (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 sin procesar del usuario).
• szName : la variable es una cadena terminada en cero ( ) "sz"; este fue uno de los prefijos sugeridos originalmente por Simonyi.

La mayoría de los prefijos sugeridos por Simonyi, aunque no todos, son de naturaleza semántica. A los ojos modernos, algunos prefijos parecen representar tipos de datos físicos, como szcadenas. Sin embargo, tales prefijos todavía eran semánticos, ya que Simonyi pretendía la notación húngara para idiomas cuyos sistemas de tipos no podían distinguir algunos tipos de datos que los idiomas modernos dan por sentado.

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

• pXes un puntero a otro tipo X ; esto 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 simplemente llamada y podría ser una posición absoluta. Esto es de naturaleza completamente semántica.
• szes una cadena terminada en nulo o cero. 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. Básicamente, no contiene ninguna información semántica y probablemente se consideraría sistemas húngaros.
• bmarca un byte, que a diferencia de w podría tener información semántica, porque en C el único tipo de datos de tamaño de byte es char , por lo que a veces se usan para contener valores numéricos. Este prefijo podría aclarar la ambigüedad entre 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 mnemónicos, no prescribe los mnemónicos en sí. Existen varias convenciones ampliamente utilizadas (ver ejemplos a continuación), pero se puede usar cualquier conjunto de letras, siempre que sean consistentes 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 sistemas húngaros 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 ahora llamada sigilos está integrada en el lenguaje y el compilador la aplica. Por ejemplo, en algunas formas de BASIC , name$nombra una cadena y count%nombra un número entero . La principal diferencia entre la notación húngara y los sigilos es que los sigilos declaran el tipo de variable en el idioma, mientras que la notación húngara es puramente un esquema de nombres sin efecto en la interpretación automática del texto del programa.

Ejemplos

• bBusy : booleano
• chInitial : carbón
• cApples : recuento de artículos
• dwLightYears: palabra  doble (Sistemas)
• fBusy : bandera (o flotante )
• nSize : número entero (Sistemas) o recuento (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 de 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 una cadena terminada en cero
• rgfpBalances : matriz de valores de punto flotante
• aulColors : matriz de largos sin firmar (Sistemas)

Si bien 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 evangelizado por "Programming Windows" de Charles Petzold , el libro original (y para muchos lectores, el definitivo) sobre programación 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 a programar Windows en C, probablemente los ejemplos más memorables sean el wParam(parámetro de tamaño de palabra) y lParam(parámetro de entero largo) para la función WindowProc ().
• hwndFoo : manejar a 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 utiliza a menudo sin la especificación de tipo húngara:

• g_nWheels : miembro de un espacio de nombres global, número entero
• m_nWheels : miembro de una estructura/clase, número 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 usa jQuery$ , a menudo se usa un prefijo para indicar que una variable contiene un objeto jQuery (a diferencia de un objeto DOM simple o algún otro valor). ^[7]

Ventajas

(Algunos de estos 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 en su nombre. Esto es útil cuando se mira el código fuera de un entorno de desarrollo integrado, como en una revisión o impresión de código, o cuando la declaración del símbolo está en otro archivo desde el punto de uso, como una función.
• En un lenguaje que utiliza escritura dinámica o que no está tipificado, las decoraciones que hacen referencia a tipos dejan de ser redundantes. En tales lenguajes, las variables generalmente no se declaran como si contuvieran un tipo particular de datos, por lo que la única pista sobre qué operaciones se pueden realizar en ellas son las sugerencias dadas por el programador, como un esquema de nomenclatura de variables, documentación y comentarios. Como se mencionó anteriormente, la notación húngara se expandió en dicho idioma ( BCPL ).
• El formato de los nombres de las variables puede simplificar algunos aspectos de la refactorización del código (al tiempo que hace que otros aspectos sean más propensos a errores).
• Se pueden usar múltiples 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 conociendo sólo sus tipos.
• Conduce a nombres de variables más consistentes.
• La conversión de tipos inapropiados y las operaciones que utilizan tipos incompatibles se pueden detectar fácilmente mientras se lee el código.
• En programas complejos con muchos objetos globales (VB/Delphi Forms), tener una notación de prefijo básica puede facilitar el trabajo de encontrar el componente dentro del editor. Por ejemplo, al buscar la cadena btnse pueden encontrar todos los objetos Botón.
• Aplicar la notación húngara de una manera más limitada, como aplicarla solo a las variables miembro , ayuda a evitar la colisión de nombres .
• El código impreso es más claro para el lector en 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 están en contra de la notación húngara de Systems , no de la notación húngara de Apps . Algunos problemas potenciales son:

• La notación húngara es redundante cuando el compilador realiza la verificación de tipos. Los compiladores de lenguajes que proporcionan una verificación de tipos estricta, como Pascal , garantizan que el uso de una variable sea coherente con su tipo automáticamente; Los controles oculares son redundantes y están sujetos 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 usa 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
• Puede generar inconsistencia cuando se modifica o se porta el 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 se deberá cambiar el nombre de la variable. Un ejemplo particularmente conocido es el tipo WPARAM estándar 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 nativa 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 un tipo de 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, 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 impedancia semántica, y por lo tanto la confusión e inconsistencia del programador de una plataforma a otra, se debe a la suposición de que 'w' representa una palabra de 16 bits y dos bytes en esos entornos diferentes.
• 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 de su tipo.
• La notación húngara reduce los beneficios de usar editores de código que admitan la finalización de nombres de variables, ya que el programador tiene que ingresar primero el especificador de tipo, que es más probable que colisione 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 sustituir de forma suficiente a nombres más descriptivos. Por ejemplo, sDatabase no le dice al lector qué es. El nombre de la base de datos podría ser un nombre más descriptivo.
• Cuando los nombres son 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 usar múltiples variables con diferente semántica en un bloque de código con nombres similares: dwTmp, iTmp, fTmp, dTmp .
• Colocar identificadores de tipo de datos o caracteres de intención como prefijo del nombre de campo o variable subvierte la capacidad, en algunos entornos de programación, de saltar a un nombre de campo o variable, alfabéticamente, cuando el usuario comienza a escribir el nombre. FileMaker, ^[9] por ejemplo, es uno de esos entornos de programación. Cuando se utiliza uno de estos entornos de programación, puede ser preferible agregar a los nombres de pila un sufijo con dichos caracteres de identificación.

Opiniones notables

• 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. Hacen que sea más difícil cambiar el nombre o 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 engañe al lector. ^[10]

• Linus Torvalds (contra Sistemas Húngaro):

  Codificar el tipo de una función en el nombre (la llamada notación húngara) es un daño cerebral: el compilador conoce los tipos de todos modos y puede verificarlos, y solo confunde al programador. ^[11]

• Steve McConnell (para aplicaciones húngaras):

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

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

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

• Joel Spolsky (para aplicaciones húngaras):

  Si lees atentamente el artículo de Simonyi, a lo que se refería era al mismo tipo de convención de nomenclatura que utilicé en mi ejemplo anterior, donde decidimos que ussignificaba una cadena insegura y suna cadena segura. Ambos son de tipo string. El compilador no le ayudará si asigna uno al otro e Intellisense [un sistema inteligente de finalización de código ] no le dirá bupkis. 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 asigna uno al otro o tendrá un error de tiempo de ejecución. Si tienes suerte. Las aplicaciones húngaras todavía tienen un enorme valor, ya que aumentan 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... (Sistemas húngaro) fue un malentendido sutil pero completo de la intención y la práctica de Simonyi. ^[4]

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

Ver también

• Convención de nomenclatura de Leszynski , una variante del húngaro para el desarrollo de bases de datos
• Caso Camel , 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 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 puedas hacer, yo puedo hacerlo Meta". Revisión de tecnología del MIT . 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). "Hacer que el código incorrecto parezca incorrecto". Joel sobre el software . Consultado el 13 de diciembre de 2005 .
5. "Estilo de codificación de Mozilla". Desarrollador.mozilla.org . Archivado desde el original el 2 de diciembre de 2019 . Consultado el 17 de marzo de 2015 .
6. "Pautas de estilo de codificación de Webkit". Webkit.org . Consultado el 17 de marzo de 2015 .
7. "¿Por qué una variable de JavaScript comenzaría con un signo de dólar?". Desbordamiento de pila . 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. pag. 727.ISBN​ 978-0-201-70917-9. Archivado (PDF) desde el 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. Martín, Robert Cecil (2008). Código limpio: un manual de artesanía de software ágil . Redmond, WA: PTR de Prentice Hall. ISBN 978-0-13-235088-4.
11. "Estilo de codificación del kernel de Linux". Documentación del núcleo de Linux . Consultado el 9 de marzo de 2018 .
12. McConnell, Steve (2004). Código completo (2ª ed.). 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. "Pautas 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 Hugariana: ahora es mi turno :) – WebLog de Larry Osterman
• Notación húngara (MSDN)
• Versión HTML del artículo de Doug Klunder ^{[ enlace muerto permanente ]}
• Convenciones de nomenclatura RVBA
• Convenciones de estilo de codificación (MSDN)