Notación húngara

La notación húngara es una convención de nomenclatura de identificadores en la programación informática, en la que el nombre de una variable o función indica su intención o tipo y, en algunos dialectos, su tipo. La notación húngara original utiliza la intención o el tipo en su convención de nomenclatura y, a veces, se denomina húngaro de aplicaciones, ya que se hizo popular en la división de aplicaciones de Microsoft en el desarrollo de Word, Excel y otras aplicaciones. A medida que la división de Microsoft Windows adoptó la convención de nomenclatura, utilizaron el tipo de datos real para la nomenclatura, y esta convención se difundió ampliamente a través de la API de Windows; esto a veces se denomina notación húngara de sistemas.

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 otros tipos de datos que no sean la palabra de máquina, nada en el lenguaje mismo ayuda a un programador a recordar las variables. tipos La notación húngara tiene como objetivo remediar esto 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 mnemotécnicos para el tipo o el propósito de esa variable, seguido 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 dado se puede escribir en mayúsculas 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 luego 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 "pareciera que estaban escritos en algún idioma extranjero inescrutable". 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 en inglés "Charles Simonyi" en húngaro era originalmente "Simonyi Károly". Del mismo modo, el nombre del tipo precede al "nombre dado" en notación húngara. El Smalltalk similar "escriba último" El estilo de denominación (por ejemplo, aPoint y lastPoint) era común en Xerox PARC durante el mandato de Simonyi allí.

El artículo de Simonyi sobre la notación se refería a los prefijos utilizados para indicar el "tipo" de la información que se almacena. Su propuesta se refería en gran medida a decorar los nombres de los identificadores en función de 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 usaba en la división de aplicaciones de Microsoft. Los sistemas húngaros se desarrollaron 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).

Sistemas húngaros frente a 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 entero largo ()"l");
• arru8NumberList: variable an array de unsigned 8-bit integers ()"arru8");
• bReadLine(bPort,&arru8NumberList): función con un código de devolución de valor byte.
• strName: Variable representa una cadena ("str") que contiene el nombre, pero no especifica cómo se implementa esa cadena.

La notación húngara de aplicaciones se esfuerza por 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 un fila ()"rw");
• usName: variable representa un cadena insegura ()"us"), que necesita ser "sanitado" antes de que se utilice (por ejemplo, ver la inyección de código y scripts cruzados para ejemplos de ataques que pueden ser causados por el uso de entrada de usuario cruda)
• szName: variable es zero-terminated string ()"sz"); este fue uno de los prefijos originales de Simonyi sugeridos.

La mayoría de los prefijos sugeridos por Simonyi, aunque no todos, son de naturaleza semántica. Para los ojos modernos, algunos prefijos parecen representar tipos de datos físicos, como sz para cadenas. Sin embargo, tales prefijos seguían siendo 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 documento original:

• pX es un puntero a otro tipo X; esto contiene muy poca información semántica.
• d es un prefijo que significa diferencia entre dos valores; por ejemplo, d Y podría representar una distancia a lo largo del eje Y de un gráfico, mientras que una variable llamada Sí. podría ser una posición absoluta. Esto es totalmente semántico en la naturaleza.
• sz es una cadena nula o cero-terminada. 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 personaje, una serie de caracteres o una cadena de cero-terminado.
• w marca una variable que es una palabra. Esto esencialmente no contiene información semántica en absoluto, y probablemente sería considerado Sistemas Húngaros.
• b marca un byte, que en contraste con w podría tener información semántica, porque en C el único tipo de datos de tamaño byte es el char, por lo que a veces se utilizan para mantener valores numéricos. Este prefijo podría aclarar la ambigüedad entre si la variable tiene un valor que debe tratarse como un personaje o un número.

Si bien la notación siempre usa letras minúsculas iniciales como mnemotécnicos, no prescribe los mnemotécnicos en sí. Existen varias convenciones ampliamente utilizadas (consulte los 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 usa 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 ahora llamada sigils está integrada en el lenguaje y el compilador la hace cumplir. 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 lenguaje, 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: boolean
• chInitial# Char #
• cApples: Conteo de artículos
• dwLightYears: doble palabra (Systems)
• fBusy: bandera (o flotador)
• nSize: entero (Systems) o cuenta (Apps)
• iSize: entero (Systems) o índice (Apps)
• fpPrice: punto flotante
• decPrice: decimal
• dbPi: doble (Systems)
• pFoo: puntero
• rgStudents: array, o rango
• szLastName: cuerda cero-terminada
• u16Identifier: entero sin firmar de 16 bits (Systems)
• u32Identifier: entero sin firmar de 32 bits (Systems)
• stTime: estructura del tiempo del reloj
• fnFunction: nombre de la función

Los mnemotécnicos 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 cero-terminada
• rgfpBalances: matriz de valores de punto flotante
• aulColors: array of unsigned long (Systems)

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 Charles Petzold's "Programming Windows", 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 comúnmente vistas son específicas de Windows:

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

La notación a veces se amplía en C++ para incluir el alcance de una variable, opcionalmente separada por un guión bajo. Esta extensión también se usa a menudo sin la especificación de tipo húngara:

• g_nWheels: miembro de un espacio global de nombres, 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 usa jQuery, se suele usar un prefijo $ para indicar que una variable contiene un objeto jQuery (en lugar de un objeto DOM simple o algún otro valor).

Ventajas

(Algunos de estos se aplican solo a los sistemas húngaros).

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

• El tipo de símbolo se puede ver desde su nombre. Esto es útil cuando se mira el código fuera de un entorno de desarrollo integrado —como en una revisión de código o impresión— o cuando la declaración de símbolo está en otro archivo desde el punto de uso, como una función.
• En un lenguaje que utiliza la escritura dinámica o que no es de tipo, las decoraciones que se refieren a tipos dejan de ser redundantes. En tales idiomas las variables normalmente no se declaran como titulares de un tipo particular de datos, por lo que la única pista de qué operaciones se pueden hacer en él son indicios dados por el programador, como un esquema de nombres variables, documentación y comentarios. Como se mencionó anteriormente, la notación húngara se expandió en tal idioma (BCPL).
• El formato de nombres variables puede simplificar algunos aspectos de la refactorización de códigos (mientras que hace otros aspectos más propensa a errores).
• Múltiples variables con semántica similar se pueden utilizar en un bloque de código: dwWidth, iWidth, fWidth, dWidth.
• Los nombres variables pueden ser fáciles de recordar sabiendo sólo sus tipos.
• Lleva a nombres variables más consistentes.
• El casting y las operaciones de tipo inapropiado utilizando tipos incompatibles se pueden detectar fácilmente al leer el código.
• En programas complejos con muchos objetos globales (VB/Delphi Forms), tener una notación básica de prefijo puede facilitar el trabajo de encontrar el componente dentro del editor. Por ejemplo, buscando la cuerda btn podría encontrar todos los objetos de Button.
• Aplicar la notación húngara de una manera más estrecha, como la aplicación sólo para variables miembros, 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, truncaciones, etc.

Desventajas

La mayoría de los argumentos contra la notación húngara son contra la notación húngara Systems, no contra la notación húngara Apps. Algunos problemas potenciales son:

• La notación húngara es redundante cuando el compilador realiza la comprobación de tipo. Compiladores para lenguajes que proporcionan un control de tipo estricto, como Pascal, aseguran que el uso de una variable es consistente con su tipo automáticamente; los cheques por ojo son redundantes y están sujetos a errores humanos.
• La mayoría de los entornos de desarrollo integrados modernos muestran tipos variables bajo demanda, y automáticamente marcan operaciones que utilizan tipos incompatibles, haciendo la notación 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, manteniendo el contenido de una columna de base de datos LastName de tipo varchar(30) que es parte de la clave principal de la tabla.
• Puede llevar a la inconsistencia cuando el código es modificado o portado. Si se cambia el tipo de variable, la decoración del nombre de la variable será incompatible con el nuevo tipo, o el nombre de la variable debe cambiarse. Un ejemplo especialmente conocido es el tipo WPARAM estándar, y el parámetro formal wParam acompañante en muchas declaraciones de funciones del sistema Windows. El '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 palabras de 16 bits, pero fue cambiado a 32 bits en arquitecturas de palabras de 32 bits, o de 64 bits en arquitecturas de palabras de 64 bits en versiones posteriores del sistema operativo mientras conserva su nombre original (su verdadero tipo subyacente es UINT_PTR, es decir, un entero no firmado lo suficientemente grande como para tener un puntero). La impedancia semántica, y por lo tanto la confusión y la inconsistencia de los programadores desde la plataforma a la plataforma, se asume que 'w' significa una palabra de dos bytes, de 16 bits en esos diferentes entornos.
• La mayor parte del tiempo, conocer el uso de una variable implica conocer su tipo. Además, si no se conoce el uso de una variable, no puede deducirse de su tipo.
• La notación húngara reduce los beneficios de usar editores de códigos que soportan la terminación de nombres variables, ya que el programador tiene que introducir primero el especificador de tipo, que es más probable que collide con otras variables que cuando usa otros esquemas de nombres.
• Hace que el código sea menos legible, obfuscando el propósito de la variable con prefijos de tipo y análisis.
• La información adicional de tipo no puede sustituir los nombres más descriptivos. Por ejemplo. sDatabase no le dice al lector lo que es. base de datos El nombre podría ser un nombre más descriptivo.
• Cuando los nombres son suficientemente descriptivos, la información adicional de tipo puede ser redundante. E.g. first El nombre es probablemente una cuerda. Así que nombrarlo sFirstName solo añade desorden al código.
• Es más difícil recordar los nombres.
• Múltiples variables diferentes semántica se puede utilizar en un bloque de código con nombres similares: DwTmp, iTmp, fTmp, dTmp.
• Colocar los identificadores de caracteres de tipo de datos o intención como un prefijo al campo o nombre de la variable El nombre de Given subvierte la capacidad, en algunos entornos de programación, de saltar a un campo o nombre variable, alfabéticamente, cuando el usuario comienza a escribir el nombre. FileMaker, por ejemplo, es uno de esos entornos de programación. Puede ser preferible al usar uno de estos entornos de programación para sufijar nombres con 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 tipo son simplemente impedimentos. Hacen más difícil cambiar el nombre o el tipo de una variable, función, miembro o clase. Hacen más difícil leer el código. Y crean la posibilidad de que el sistema de codificación engañará al lector.

• Linus Torvalds (contra Sistemas Húngaros):

  Codificar el tipo de función en el nombre (llamado notación húngara) está dañado por el cerebro, el compilador conoce los tipos de todos modos y puede comprobarlos, y sólo confunde al programador.

• Steve McConnell (para aplicaciones húngaras):

  Aunque la convención húngara de nombramiento ya no está en uso generalizado, la idea básica de estandarizar en terse, abreviaturas precisas sigue teniendo valor. Los prefijos estandarizados le permiten comprobar los tipos con precisión cuando está utilizando tipos de datos abstractos que su compilador no puede verificar necesariamente.

• Bjarne Stroustrup (contra Sistemas Húngaros para C++):

  No, no recomiendo 'Hungría'. Considero 'Hungariano' (enumerar una versión abreviada de un tipo en un nombre variable) como una técnica que puede ser útil en idiomas no escritos, pero es completamente inadecuado para un lenguaje que apoye la programación genérica y la programación orientada al objeto, ambos enfatizan la selección de operaciones basadas en el tipo y los argumentos (conocido al idioma o al soporte de ejecución). En este caso, 'construir el tipo de objeto en nombres' simplemente complica y minimiza la abstracción.

• Joel Spolsky (para aplicaciones húngaras):

  Si lees el periódico de Simonyi de cerca, lo que estaba recibiendo era el mismo tipo de convención de nombres que usé en mi ejemplo anterior donde decidimos que us significa cadena insegura y s significó una cuerda segura. Ambos son de tipo string. El compilador no te ayudará si asignas uno al otro e Intellisense [un sistema de compleción de código inteligente] no te dirá bupkis. Pero son semánticamente diferentes. Necesitan ser interpretados de manera diferente y tratados de manera diferente y algún tipo de función de conversión tendrá que ser llamado si usted asigna uno al otro o usted tendrá un error de tiempo de ejecución. Si tienes suerte. Todavía hay una enorme cantidad de valor para las aplicaciones húngaras, ya que aumenta la ubicación del 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 erróneo.... (Systems Húngaro) fue un sutil pero completo malentendido de la intención y práctica de Simonyi.

• Las Directrices de Diseño de Microsoft desalientan a los desarrolladores de utilizar la notación de Sistemas Húngaros cuando eligen nombres para los elementos en. Bibliotecas de clase NET, aunque era común en plataformas de desarrollo anteriores de Microsoft como Visual Basic 6 y antes. Estas Directrices de diseño no guardan relación con las convenciones de nombres de variables locales dentro de funciones.