La notación húngara es una convención de nombres que indica el tipo o propósito de variables y funciones mediante prefijos. Existen dos tipos: la notación de sistemas húngaros, donde los prefijos indican el tipo de datos real, y la notación de aplicaciones húngaras, donde los prefijos indican el tipo lógico o propósito. La notación húngara fue creada originalmente por Charles Simonyi y se adoptó ampliamente en Microsoft para lenguajes como C. Aunque provee información sobre tipos, también puede hacer los n

1. NOTACIÓN HÚNGARA
La notación húngara es una convención de nombres identificador de programación
informática, en la que el nombre de una variable o función indica el tipo o uso previsto. Hay dos
tipos de notación húngara: Sistemas de notación húngara y aplicaciones notación húngara.
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 BCPL tiene ningún tipo de datos que
no sean la palabra de la máquina, no hay nada en la propia lengua ayuda a un programador recordar
variables de tipos. Notación húngara tiene como objetivo remediar esto proporcionando el
programador con conocimiento explícito de tipo de datos de cada variable.
En la notación húngara, un nombre de variable empieza con un grupo de letras minúsculas
que son mnemotécnicos para el tipo o propósito de esa variable, seguido por el nombre que el
programador ha elegido; esta última parte a veces se distingue por ser el nombre dado. El primer
carácter del nombre que puede ser capitalizado para separarlo de los indicadores de tipo. De lo
contrario el caso de este carácter denota alcance.
Historia
La notación húngara original, que ahora se llamaría Aplicaciones húngaro, fue inventada por
Charles Simonyi, un programador que trabajaba en Xerox PARC circa 1972-1981, y que más tarde se
convirtió en arquitecto jefe de Microsoft. Puede haber sido derivado del principio anterior de utilizar
la primera letra del nombre de una variable para ajustar su tipo - por ejemplo, las variables cuyos
nombres comenzaron con las letras I a N en FORTRAN son enteros por defecto.
La notación es una referencia a la nación de Simonyi de origen, nombres de las personas
húngaras se "invierten" en comparación con la mayoría de los nombres europeos, el apellido
precede al nombre. Por ejemplo, el nombre anglicismo "Charles Simonyi" en húngaro era
originalmente "Charles Simonyi". De la misma manera el nombre del tipo precede al "nombre" en
la notación húngara en lugar de la más natural, la mayoría europeos, "type última" Smalltalk
nombramiento estilo por ejemplo unPunto y lastPoint. Este estilo de denominación esta última era
más común en el Xerox PARC durante el mandato de Simonyi allí.
El nombre Aplicaciones húngaro fue acuñado desde la convención se utilizó en la división
de aplicaciones de Microsoft. Sistema húngaro 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
la información que se almacena. Su propuesta fue en gran parte que ver con nombres de
identificadores de decoración en base a la información semántica de lo que almacenan, en
consonancia con aplicaciones húngaro. Sin embargo, sus sugerencias no fueron enteramente
distinto de lo que se conoce como Sistemas de Hungría, ya que algunos de sus prefijos propuestos
contienen poca o ninguna información semántica.
La notación húngara plazo es memorable por muchas personas debido a que las cadenas de
consonantes impronunciables vagamente se parecen a la consonante-rica ortografía de algunas
lenguas de Europa del Este a pesar de que Hungría es un lenguaje Uralic, ya diferencia de las lenguas

2. eslavas es bastante rico en vocales. Por ejemplo, el prefijo de cadena terminada en cero "sz"
también es una letra del alfabeto húngaro.
Sistemas vs Aplicaciones húngaro
Cuando los sistemas de notación y la notación aplicaciones difieren es en el fin de los prefijos.
En la notación húngara Sistemas, el prefijo codifica el tipo de datos real de la variable. Por ejemplo:
 lAccountNum: variable es un entero largo;
 arru8NumberList: variable es una matriz de un entero sin signo de 8 bits;
 szName: variable es una cadena terminada en cero, lo que fue uno de los prefijos
sugeridos originales de Simonyi.
 Breadline: función con un código de retorno de valor de byte.
Aplicaciones notación húngara se esfuerza para codificar el tipo de datos lógicos en lugar del tipo
de datos físicos, de esta manera, da una idea de lo que el propósito de la variable es, o lo que
representa.
 rwPosition: variable representa una fila;
 usName: variable representa una cadena insegura, que debe ser "saneada" antes de su
uso
 strNombre: Variable representa una cadena que contiene el nombre, pero no específica
cómo se aplica esa cadena.
La mayoría, pero no todos, de los prefijos Simonyi sugeridas son de naturaleza semántica. Los
siguientes son ejemplos del documento original:
 pX: es un puntero a otro tipo X, lo que 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 sólo una
variable llamada y podría ser una posición absoluta. Esto es totalmente de naturaleza
semántica.
 Sz: es una cadena nula o terminada en cero. En C, este contiene alguna información
semántica, ya que no está claro si una variable de tipo char * es un puntero a un carácter
individual, un conjunto de caracteres o una cadena terminada en cero.
 W: representa una variable que es una palabra. Este no contiene esencialmente
información semántica en absoluto, y probablemente ser considerado Sistemas
húngaro.
 b: representa un byte, que en contraste con w pueda disponer de información
semántica, porque en C el único tipo de datos byte de tamaño es el carbón, por lo que
éstos se utilizan a veces para contener valores numéricos. Este prefijo puede eliminar la
ambigüedad entre si la variable es la celebración de un valor que debe ser tratado como
un carácter o un número.

3. Mientras la notación siempre utiliza letras minúsculas iniciales como mnemotécnicos, no
prescribe la nemotécnica sí mismos. Hay varias convenciones ampliamente utilizadas, pero
cualquier conjunto de letras se pueden utilizar, siempre y cuando sean compatibles dentro de un
cuerpo de código dado.
Es posible que el código utilizando aplicaciones notación húngara para contener a veces
Sistemas húngaros al describir las variables que se definen únicamente en función de su tipo.
Relación con sigilos
En algunos lenguajes de programación, una notación parecida llama ahora sigilos está
integrado en el lenguaje y aplicadas por el compilador. Por ejemplo, en algunas formas de BASIC,
name $ nombres una cadena y count% nombres de un número entero. La principal diferencia entre
la notación y sigilos húngaro es que los sigilos declarar el tipo de la variable para el compilador,
mientras que la notación húngara es puramente un esquema de nombres.
Ejemplos
 bBusy: boolean
 chInitial: char
 cApples: recuento de los elementos
 dwLightYears: palabra doble
 fBusy: boolean
 nSize: integer o recuento
 ISIZE: integer o índice
 fpPrice: coma flotante
 dbPi: double
 Pfoo: Puntero
 rgStudents: matriz o rango
 szLastName: string terminado en cero
 u32Identifier: entero sin signo de 32 bits
 stTime: Estructura de la hora del reloj
 fnFunction: nombre de la función
Los mnemónicos para punteros y matrices, que no son tipos de datos reales, son seguidos
generalmente por el tipo del elemento de datos en sí:
 pszOwner: Puntero a una cadena terminada en cero
 rgfpBalances: array de valores de punto flotante
 aulColors: array de unsigned long
Mientras que la notación húngara se puede aplicar a cualquier lenguaje de programación y
el medio ambiente, que fue ampliamente adoptado por Microsoft para su uso con el lenguaje C, en
particular, para Microsoft Windows, y su uso sigue siendo limitado en gran medida a esa área. En
particular, el uso de la notación húngara fue ampliamente evangelizada por Charles Petzold

4. "Programming Windows", el libro original de programación API de Windows. Por lo tanto, muchas
construcciones comúnmente vistos de notación húngara son específicos de Windows:
 Para los programadores que aprendieron de programación de Windows en C,
probablemente los ejemplos más memorables son el wParam y lParam para la
función WindowProc.
 hwndFoo: identificador de una ventana
 lpszBar: puntero largo a una cadena terminada en cero
La notación a veces se extiende en C para incluir el ámbito de una variable, separados por un guión
bajo. Esta extensión se utiliza a menudo también sin el tipo de especificación de Hungría:
 g_nWheels: miembros de un espacio de nombres global, entero
 m_nWheels: miembros de una estructura/clase, número entero
 m_wheels, _Ruedas: miembros de una estructura/clase
 s_wheels: miembros estáticos de una clase
 c_wheels: Miembro estático de una función
Ventajas
Los partidarios argumentan que los beneficios de la notación húngara incluyen:
 El tipo de variable se puede ver a partir de su nombre. .
 El tipo de valor devuelto por una función se determina sin búsqueda
 El formato de los nombres de las variables puede simplificar algunos aspectos de
refactorización de código.
 Múltiples variables con semántica similares pueden ser utilizados en un bloque de
código: dwWidth, iWidth, fWidth, dancho
 Los nombres de variables pueden ser fácil de recordar de conocer sólo sus tipos.
 Esto lleva a los nombres de variables más consistentes
 Tipo inapropiados fundición y operaciones con tipos incompatibles se pueden detectar
fácilmente durante la lectura de código de
 Es útil con lenguajes basados en cadenas donde numéricos son cadenas
 En Aplicaciones húngaro, los guardias nombre de la variable contra el uso en una
operación inadecuada con el mismo tipo de datos al hacer que el error evidente como
en:
 heightWindow = window.getWidth
 Al programar en un lenguaje que utiliza tipado dinámico o que está completamente sin
tipo, los adornos que se refieren a los tipos dejan de ser redundante. Estos idiomas no
suelen incluir declaraciones de tipos, por lo que las únicas fuentes de qué tipos se
permiten son los mismos nombres, documentación, tales como comentarios y por la
lectura del código de entender lo que hace. En estos idiomas, incluyendo una indicación
del tipo de una variable puede ayudar al programador. Como se mencionó
anteriormente, la notación húngara se expandió en un lenguaje.

5.  En programas complejos con una gran cantidad de objetos globales, con una notación
básica prefijo puede facilitar el trabajo de búsqueda de la parte interior del editor.
Escribiendo btn y presionando causas del editor para que aparezca una lista de los
objetos Button.
 La aplicación de la notación húngara de una manera más estrecha, tales como la
aplicación sólo para variables miembro ayuda a evitar la colisión de nombres.
Desventajas
La mayoría de los argumentos en contra de la notación húngara son objeto los sistemas de notación
húngara, no aplicaciones notación húngara. Algunos temas posibles son:
 La notación húngara es redundante cuando el tipo de comprobación se realiza por el
compilador. Compiladores para lenguajes proporcionan tipo de comprobación de
garantizar el uso de una variable es coherente con el tipo de forma automática, los
controles de los ojos son redundantes y sujeto a errores humanos.
 Todos los entornos de desarrollo integrados modernos muestran los tipos de variables
en la demanda, y de forma automática operaciones de bandera que utilizan tipos
incompatibles, por lo que la notación en gran medida obsoleta.
 Notación húngara vuelve confuso cuando se utiliza para representar varias propiedades,
como en a_crszkvc30LastNameCol: un argumento de referencia constante, que sostiene
el contenido de una base de datos de la columna Apellidos de tipo VARCHAR que es
parte de la clave primaria de la tabla.
 Puede dar lugar a incoherencias cuando el código se modifica o portado. Si se cambia el
tipo de una variable, ya sea la decoración en el nombre de la variable será incompatible
con el nuevo tipo, o el nombre de la variable debe ser cambiado. Un ejemplo muy
conocido es el tipo WPARAM estándar, y el parámetro formal wParam acompañante en
muchas declaraciones de función de sistema de Windows. La 'w' significa 'palabra',
donde 'palabra' es el tamaño de la 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 una de 32 bits en arquitectura de palabras de 32 bits o 64 bits de tipo
de arquitecturas de palabras de 64 bits en versiones posteriores del sistema operativo
sin perder su nombre original. La impedancia de semántica, y por lo tanto la confusión
programador y la inconsistencia de plataforma en plataforma, es en el supuesto de que
'w' significa 16 bits en los diferentes entornos.
 La mayor parte del tiempo, sabiendo que el uso de una variable implica conocer su tipo.
Por otra parte, si no se conoce el uso de una variable, no puede deducirse de su tipo.
 Hace código menos legible, por ofuscar el propósito de la variable con el tipo de huelga
y los prefijos de alcance.
 La información de tipo adicional puede sustituir insuficientemente nombres más
descriptivos. Por ejemplo sDatabase no le dice al lector lo que es. databaseName podría
ser un nombre más descriptivo.

6.  Cuando los nombres son suficientemente descriptivos, la información de tipo adicional
puede ser redundante. Por ejemplo firstName es más probable una cadena. Así
nombrarlo sFirstName sólo añade confusión al código.
 Es difícil recordar los nombres.
Opiniones notables
 Robert C. Martin:
"Hoy en día... HN y otras formas de codificación tipo son simplemente obstáculos. Ellos
hacen que sea más difícil para cambiar el nombre o el tipo de una variable, función, o
miembro de la clase. Ellos hacen que sea más difícil de leer el código. Ellos crean la
posibilidad de que el sistema de codificación se induzca a error al lector”.
 Linus Torvalds:
"Codificación del tipo de una función en el nombre es cerebro dañado-el compilador
sabe los tipos de todos modos y puede comprobar aquellos, y sólo confunde el
programador."
 Steve McConnell:
"A pesar de la convención de nomenclatura de Hungría ya no es de uso generalizado, la
idea básica de la estandarización en concisas, precisas abreviaturas sigue teniendo
valor. Prefijos estandarizados permiten comprobar los tipos de precisión cuando se está
utilizando tipos de datos abstractos que el compilador no puede necesariamente
marque”.
 Bjarne Stroustrup:
"No, no lo recomiendo" húngaro”. Considero 'húngaro' una técnica que puede ser útil
en las lenguas sin tipo, pero es totalmente inadecuado para un lenguaje de
programación que soporte genérico y programación orientada a objetos, tanto de los
que hacen hincapié en la selección de las operaciones en función del tipo un
argumentos. En este caso, "la construcción del tipo de un objeto en los nombres
'simplemente complica y reduce al mínimo la abstracción".
 Joel Spolsky:
"Si usted lee el artículo de Simonyi de cerca, lo que quería llegar era el mismo tipo de
convención de nombres como lo hacía en mi ejemplo anterior donde decidimos que
significa eso de" cadena insegura "y s significa" cadena de seguridad". Son los dos tipos
cadena. El compilador no le ayudará si asigna una a la otra e Intellisense no le dirá
bupkis. Pero son semánticamente diferentes. Tienen que ser interpretado de manera
diferente y se tratan de manera diferente y algún tipo de función de conversión tendrá
que llamar si asignar una a la otra, o usted tendrá un error de tiempo de ejecución. Si
tiene suerte. Todavía hay una enorme cantidad de valor a las aplicaciones de Hungría,
ya que aumenta la función de proximidad 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, tiene un código
incorrecto mirar mal. "

7.  Instrucciones de diseño de Microsoft desalientan a los desarrolladores de utilizar la
notación húngara cuando eligen nombres para los elementos de. NET Class Libraries,
aunque era común en las plataformas de desarrollo de Microsoft anteriores como Visual
Basic 6 y anteriores. Estas Instrucciones de diseño no se pronuncian sobre las
convenciones de nomenclatura para las variables locales dentro de funciones.