La notación húngara es una convención de nomenclatura de identificadores en la programación de computadoras , 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 usa intencionalidad o amabilidad en su convención de nomenclatura y, a veces, se la denomina Apps húngaro, ya que se hizo popular en la división de Microsoft Apps 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.
Booch : A menos que continúe con la notación húngara.
Simonyi : Absolutamente ... pasamos a los idiomas mecanografiados también más tarde ... Pero ... veríamos un nombre y les diría 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 otros tipos de datos que no sean la palabra de la máquina , nada en el lenguaje en sí ayuda al programador a recordar los tipos de variables. 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 nemotécnicas para el tipo o propósito de esa variable, seguidas del 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 caso de este carácter denota alcance.
Historia
La notación húngara original, que ahora se llamaría Apps húngaro, fue inventada por Charles Simonyi , un programador que trabajó en Xerox PARC alrededor de 1972-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; 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 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, en lugar del estilo de denominación "último tipo" de Smalltalk (por ejemplo, aPoint y lastPoint). Este último estilo de denominación fue más común en Xerox PARC durante el mandato de Simonyi allí.
El nombre Apps húngaro se inventó desde que la convención se usó en la división de aplicaciones de Microsoft. Systems Hungarian se desarrolló más tarde en el equipo de desarrollo de Microsoft Windows . El artículo de Simonyi se refirió a los prefijos utilizados para indicar el "tipo" de información que se almacena. Su propuesta se centró en gran medida en decorar nombres de identificadores basados en la información semántica de lo que almacenan (en otras palabras, el propósito de la variable ), de acuerdo con Apps húngaro. Sin embargo, sus sugerencias no fueron completamente distintas de lo que se conoció como sistemas húngaros, ya que algunos de sus prefijos sugeridos contienen poca o ninguna información semántica (ver ejemplos a continuación).
Sistemas húngaro frente a aplicaciones húngaro
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
: la variable es un entero largo ("l"
);arru8NumberList
: Variable es un arr ay de u nsigned 8 números enteros -bit ("arru8"
);bReadLine(bPort,&arru8NumberList)
: función con un código de retorno 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 Apps 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 una fila ("rw"
);usName
: la variable representa una cadena insegura ("us"
), que debe ser "desinfectada" antes de que se use (por ejemplo, consulte la inyección de código y las secuencias de comandos entre sitios para ver ejemplos de ataques que pueden ser causados por el uso de datos sin procesar del usuario)szName
: la variable es una s tring ( ) terminada en z ero"sz"
; este fue uno de los prefijos sugeridos originalmente por Simonyi.
La mayoría, pero no todos, de los prefijos sugeridos por Simonyi son de naturaleza semántica. Para los ojos modernos, algunos prefijos parecen representar tipos de datos físicos, como sz
cadenas. Sin embargo, esos prefijos seguían siendo semánticos, ya que Simonyi pretendía la notación húngara para los 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: [2]
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, 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.sz
es una cadena terminada en cero o nulo. En C, esto contiene 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.w
marca una variable que es una palabra. Esto esencialmente no contiene información semántica en absoluto, y probablemente se consideraría System Hungarian.b
marca un byte, que en contraste con w podría tener información semántica, porque en C el único tipo de datos del tamaño de un byte es el char , por lo que a veces se usan para contener valores numéricos. Este prefijo puede 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 usa letras minúsculas iniciales como mnemotécnicos, no prescribe los propios mnemónicos. Hay varias convenciones de uso generalizado (consulte los 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 usa la notación húngara de Apps a veces contenga Systems húngaro al describir variables que se definen únicamente en términos de su tipo.
Relación con los sigilos
En algunos lenguajes de programación, el compilador incorpora una notación similar que ahora se llama sigilos . 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 nomenclatura sin efecto sobre la interpretación automática del texto del programa.
Ejemplos de
bBusy
: booleanochInitial
: charcApples
: recuento de elementosdwLightYears
: palabra doble (Sistemas)fBusy
: bandera (o flotador )nSize
: entero (sistemas) o recuento (aplicaciones)iSize
: entero (sistemas) o índice (aplicaciones)fpPrice
: punto flotantedbPi
: doble (Sistemas)pFoo
: punterorgStudents
: matriz o rangoszLastName
: cadena terminada en cerou16Identifier
: entero de 16 bits sin signo (sistemas)u32Identifier
: entero de 32 bits sin signo (sistemas)stTime
: estructura de la hora del relojfnFunction
: 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 cerorgfpBalances
: matriz de valores de punto flotanteaulColors
: matriz de unsigned long (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 se limita en gran medida a esa área. En particular, el uso de la notación húngara fue ampliamente evangelizada por Charles Petzold 's 'de Windows Programación' , el original (y para muchos lectores, la definitiva) libro sobre la API de Windows de programación. 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 la programación de Windows en C, probablemente los ejemplos más memorables son el
wParam
(parámetro de tamaño de palabra) ylParam
(parámetro de entero largo) para la función WindowProc (). hwndFoo
: manija a una ventanalpszBar
: 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. [3] [4] 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, enterom_nWheels
: miembro de una estructura / clase, enterom_wheels
,_wheels
: miembro de una estructura / clases_wheels
: miembro estático de una clasec_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 (en comparación con un objeto DOM simple o algún otro valor). [5]
Ventajas
(Algunos de estos se aplican solo al sistema húngaro).
Los partidarios argumentan que los beneficios de la notación húngara incluyen: [2]
- 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 usa mecanografía dinámica o que no está mecanografiado , las decoraciones que hacen referencia a tipos dejan de ser redundantes. En tales lenguajes, las variables normalmente no se declaran como que contienen un tipo particular de datos, por lo que la única pista sobre qué operaciones se pueden realizar 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 formateo 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 si solo se conocen 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 se
btn
pueden encontrar todos los objetos Button. - Aplicar la notación húngara de una manera más restringida, como aplicar solo para 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 sistemas , no 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 de forma automática; los controles a simple vista son redundantes y están sujetos a errores humanos.
- La mayoría de los entornos de desarrollo integrados modernos muestran tipos de variables bajo demanda y señalan automáticamente las operaciones que utilizan tipos incompatibles, lo que hace que la notación sea 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 la base de datos LastName de tipo varchar (30) que es parte de la clave principal de la tabla .
- Puede dar lugar a inconsistencias cuando el código se modifica o se porta. Si se cambia el tipo de una variable, la decoración en el nombre de la variable será inconsistente con el nuevo tipo, o el nombre de la variable debe cambiarse. 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 de 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 un tipo de 64 bits en arquitecturas de palabras de 64 bits en versiones posteriores del sistema operativo mientras conservaba 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 tanto, la confusión e inconsistencia del programador de plataforma a plataforma, se basa en el supuesto de que 'w' representa una palabra de dos bytes y 16 bits en esos entornos diferentes.
- La mayoría de las veces, conocer el uso de una variable implica conocer su tipo. Además, si se desconoce 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 en nombres de variables, ya que el programador tiene que ingresar primero el especificador de tipo, que es más probable que choque con otras variables que cuando se usan otros esquemas de nombres.
- Hace que el código sea menos legible, al ocultar el propósito de la variable con prefijos de tipo y ámbito. [6]
- La información de tipo adicional no puede reemplazar suficientemente los 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 suficientemente descriptivos, la información de tipo adicional puede ser redundante. Por ejemplo, firstName es probablemente una cadena. Así que 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 carácter de tipo de datos o intención como un prefijo al 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, [7] por ejemplo, es uno de esos entornos de programación. Puede ser preferible, al utilizar uno de estos entornos de programación, agregar el sufijo de los nombres de pila con dichos caracteres identificativos.
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 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 engañe al lector. [8]
- Linus Torvalds (contra Systems Hungarian):
Codificar el tipo de una función en el nombre (la denominada notación húngara) tiene un daño cerebral; el compilador conoce los tipos de todos modos y puede verificarlos, y solo confunde al programador. [9]
- Steve McConnell (para Apps húngaro):
Aunque la convención de nomenclatura húngara ya no es de uso generalizado, 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 usa tipos de datos abstractos que su compilador no necesariamente puede verificar. [10]
- Bjarne Stroustrup (contra Systems Hungarian para C ++):
No, no recomiendo 'húngaro'. Considero 'húngaro' (incrustando 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 admite programación genérica y programación orientada a objetos, los cuales enfatizan selección de operaciones basadas en el tipo y argumentos (conocidos por el idioma o por el soporte en tiempo de ejecución). En este caso, 'construir el tipo de un objeto en nombres' simplemente complica y minimiza la abstracción. [11]
- Joel Spolsky (para Apps húngaro):
Si lees el artículo de Simonyi con atención, lo que él quería decir era el mismo tipo de convención de nomenclatura que usé en mi ejemplo anterior, donde decidimos que eso
us
significa cadena insegura ys
significa cadena segura. Ambos son de tipostring
. El compilador no le ayudará si asigna uno al otro e Intellisense [un sistema inteligente de finalización de código ] no le dirá los bupkis . Pero son semánticamente diferentes. Deben interpretarse de manera diferente y tratarse de manera diferente y será necesario llamar a algún tipo de función de conversión si asigna una a la otra o tendrá un error de tiempo de ejecución. Si tienes suerte. Todavía hay una gran cantidad de valor para 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 ... (Sistemas Húngaro) fue un malentendido sutil pero completo de la intención y la práctica de Simonyi. [12] - Las pautas de diseño de Microsoft [13] desalientan a los desarrolladores de usar 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 guardan silencio sobre las convenciones de nomenclatura para las variables locales dentro de funciones.
Ver también
- Convención de nomenclatura de Leszynski , notación húngara para el desarrollo de bases de datos
- Notación polaca
- PascalCase
Referencias
- ^ "Historia oral de Charles Simonyi" (PDF) . Archive.computerhistory.org \ accessdate = 5 de agosto de 2018 .
- ^ a b Charles Simonyi (noviembre de 1999). "Notación húngara" . Biblioteca de MSDN . Microsoft Corp.
- ^ "Estilo de codificación de Mozilla" . Developer.mozilla.org . Consultado el 17 de marzo de 2015 .
- ^ "Pautas de estilo de codificación de Webkit" . Webkit.org . Consultado el 17 de marzo de 2015 .
- ^ "¿Por qué una variable de JavaScript comenzaría con un signo de dólar?" . Desbordamiento de pila . Consultado el 12 de febrero de 2016 .
- ^ Jones, Derek M. (2009). El nuevo estándar C: un comentario económico y cultural (PDF) . Addison-Wesley. pag. 727. ISBN 978-0-201-70917-9.
- ^ "Haga una aplicación para cualquier tarea - FileMaker - Una subsidiaria de Apple" . Filemaker.com . Consultado el 5 de agosto de 2018 .
- ^ Martin, Robert Cecil (2008). Código limpio: un manual de artesanía de software ágil . Redmond, WA: Prentice Hall PTR. ISBN 978-0-13-235088-4.
- ^ "Estilo de codificación del kernel de Linux" . Documentación del kernel de Linux . Consultado el 9 de marzo de 2018 .
- ^ McConnell, Steve (2004). Código completo (2ª ed.). Redmond, WA: Microsoft Press . ISBN 0-7356-1967-0.
- ^ Stroustrup, Bjarne (2007). "Preguntas frecuentes sobre la técnica y el estilo C ++ de Bjarne Stroustrup" . Consultado el 15 de febrero de 2015 .
- ^ Spolsky, Joel (11 de mayo de 2005). "Hacer que el código incorrecto parezca incorrecto" . Joel en software . Consultado el 13 de diciembre de 2005 .
- ^ "Pautas de diseño para desarrollar 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í :) - WebLog de Larry Osterman
- Notación húngara (MSDN)
- Versión HTML del artículo de Doug Klunder
- Convenciones de nomenclatura de RVBA
- Convenciones de estilo de codificación (MSDN)