¿Cuál es el beneficio de no usar la notación húngara?

Una de las cosas con las que lucho es no usar la notación húngara. Yo no quiero tener que ir a la definición de la variable sólo para ver qué tipo es. Cuando un proyecto se vuelve extenso, es bueno poder mirar una variable con el prefijo 'bool' y saber que está buscando verdadero / falso en lugar de un valor 0/1 .

También hago mucho trabajo en SQL Server. Prefijo mis procedimientos almacenados con 'sp' y mis tablas con 'tbl', sin mencionar todas mis variables en la base de datos respectivamente.

Veo en todas partes que nadie realmente quiere usar la notación húngara, hasta el punto de evitarla. Mi pregunta es, ¿cuál es el beneficio de no usar la notación húngara y por qué la mayoría de los desarrolladores lo evitan como la peste?

Porque su intención original (ver http://www.joelonsoftware.com/articles/Wrong.html y http://fplanque.net/Blog/devblog/2005/05/11/hungarian_notation_on_steroids ) ha sido mal entendida y ha sido ( ab) se usa para ayudar a las personas a recordar qué tipo de variable es cuando el lenguaje que usan no está tipeado estáticamente. En cualquier idioma escrito estáticamente, no necesita el balasto agregado de prefijos para decirle qué tipo de variable es. En muchos lenguajes de script sin tipo puede ayudar, pero a menudo se ha abusado de él hasta el punto de volverse totalmente difícil de manejar. Desafortunadamente, en lugar de volver a la intención original de la notación húngara, la gente acaba de convertirla en una de esas cosas "malvadas" que debes evitar.

La notación húngara en resumen pretendía prefijar variables con alguna semántica. Por ejemplo, si tiene coordenadas de pantalla (izquierda, arriba, derecha, abajo), prefijaría variables con posiciones absolutas de pantalla con " abs" y variables con posiciones relativas a una ventana con " rel". De esa manera, sería obvio para cualquier lector cuando pasara una coordenada relativa a un método que requiera posiciones absolutas.

actualización (en respuesta al comentario de delnan)

En mi humilde opinión, la versión abusada debe evitarse como la peste porque:

• complica el nombramiento. Cuando (ab) use la notación húngara, siempre habrá discusiones sobre cuán específicos deben ser los prefijos. Por ejemplo: listboxXYZo MyParticularFlavourListBoxXYZ.
• alarga los nombres de las variables sin ayudar a comprender para qué sirve la variable.
• de alguna manera derrota el objeto del ejercicio cuando, para evitar prefijos largos, estos se acortan a abreviaturas y necesitas un diccionario para saber qué significa cada abreviatura. ¿Es un uientero sin signo? una interfaz contada sin referencia? algo que ver con las interfaces de usuario? Y esas cosas pueden ser larga . He visto prefijos de más de 15 caracteres aparentemente aleatorios que se supone que transmiten el tipo exacto de la var pero en realidad solo mistifican.
• se desactualiza rápidamente. Cuando cambia el tipo de una variable, las personas invariablemente (lol) olvidan actualizar el prefijo para reflejar el cambio, o deliberadamente no lo actualizan porque eso provocaría cambios en el código en todas partes donde se usa el var ...
• complica hablar de código porque como "@g". dijo: Los nombres de variables con notación húngara son típicamente una sopa de letras difícil de pronunciar. Esto inhibe la legibilidad y la discusión del código, porque no puede 'decir' ninguno de los nombres.
• ... mucho más que no puedo recordar en este momento. Tal vez porque he tenido el placer de no tener que lidiar con la notación húngara abusada durante mucho tiempo ...

La notación húngara es un antipatrón de denominación en entornos de programación modernos y forma de tautología .

Inútilmente repite información sin beneficio y gastos adicionales de mantenimiento. Lo que sucede cuando cambia su inta un tipo diferente long, ahora tiene que buscar y reemplazar toda su base de código para cambiar el nombre de todas las variables o ahora están semánticamente incorrectas, lo que es peor que si no hubiera duplicado el tipo en el nombre.

Viola el principio SECO. Si tiene que anteponer las tablas de su base de datos con una abreviatura para recordarle que es una tabla, entonces definitivamente no está nombrando sus tablas semánticamente de manera descriptiva. Lo mismo ocurre con cualquier otra cosa con la que esté haciendo esto. Es solo un tipeo adicional y funciona sin ganancia ni beneficio con un entorno de desarrollo moderno.

Wikipedia tiene una lista de ventajas y desventajas de la notación húngara y, por lo tanto, probablemente puede proporcionar la respuesta más completa a esta pregunta. Las opiniones notables también son una lectura bastante interesante.

El beneficio de no usar la notación húngara es básicamente evitar sus desventajas:

• La notación húngara es redundante cuando el compilador realiza la verificación de tipo. Los compiladores para idiomas que proporcionan verificación de tipos aseguran que el uso de una variable sea consistente con su tipo automáticamente; los controles a simple vista son redundantes y están sujetos a errores humanos.

• Todos los entornos de desarrollo integrados modernos muestran tipos variables bajo demanda y marcan automáticamente las operaciones que usan tipos incompatibles, lo que hace que la notación quede 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 LastNamede tipo de base de datos varchar(30)que es parte de la clave primaria de la tabla.

• Puede provocar inconsistencias cuando el código se modifica o se transfiere. Si se cambia el tipo de una variable, la decoración en el nombre de la variable será inconsistente con el nuevo tipo, o se debe cambiar el nombre de la variable. Un ejemplo particularmente conocido es el WPARAMtipo estándar y el wParamparámetro formal 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 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 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 esUINT_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 plataforma a plataforma, se supone que 'w' representa 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 no se conoce el uso de una variable, no se puede deducir de su tipo.

• La notación húngara reduce en gran medida los beneficios del uso de editores de código ricos en funciones que admiten la finalización de nombres de variables, ya que el programador tiene que ingresar primero el especificador de tipo completo.

• Hace que el código sea menos legible, al ofuscar el propósito de la variable con tipos innecesarios y prefijos de alcance.

• La información de tipo adicional puede reemplazar insuficientemente nombres más descriptivos. Por ejemplo, sDatabaseno le dice al lector lo que es. databaseNamepodría ser un nombre más descriptivo.

• Cuando los nombres son suficientemente descriptivos, la información de tipo adicional puede ser redundante. Por ejemplo, firstNamelo más probable es una cadena. Entonces nombrarlo sFirstNamesolo agrega desorden al código.

Yo mismo no uso esta notación, porque no me gusta el ruido técnico innecesario. Casi siempre sé con qué tipo estoy tratando y quiero un lenguaje limpio en mi modelo de dominio, pero escribo principalmente en lenguajes estáticos y fuertemente tipados.

Como un problema específico de MS SQL Server:

Los procedimientos almacenados con el prefijo 'sp_' se buscan primero en la base de datos maestra en lugar de en la que se crean. Esto provocará un retraso en la ejecución del procedimiento almacenado.

En mi opinión, el mayor beneficio de no usar húngaro es el hecho de que te obliga a usar nombres significativos . Si nombra las variables correctamente, debe saber de inmediato de qué tipo es o poder deducirlo con bastante rapidez en cualquier sistema bien diseñado. Si necesita confiar en, stro blnpeor de todos, los objprefijos para saber de qué tipo es una variable, diría que indica un problema de nomenclatura, ya sea nombres de variables pobres en general o demasiado genéricos para transmitir significado.

Irónicamente, por experiencia personal, el escenario principal que he visto usar en húngaro es la programación de "carga-cult" (es decir, otro código lo usa, así que continuemos usándolo solo porque) o en VB.NET para solucionar el hecho de que el idioma es no distingue entre mayúsculas y minúsculas (p. ej., Person oPerson = new Personporque no se puede usar Person person = new Persony Person p = new Persones demasiado vago); También he visto prefijar "el" o "mi" en su lugar (como en Person thePerson = new Persono el más feo Person myPerson = new Person), en ese caso particular.

Agregaré la única vez que uso húngaro tiende a ser para controles ASP.NET y eso es realmente una cuestión de elección. Me parece muy feo escribir TextBoxCustomerNameo CustomerNameTextBoxcontra el más simple txtCustomerName, pero incluso eso se siente "sucio". Creo que debería usarse algún tipo de convención de nomenclatura para los controles, ya que puede haber múltiples controles que muestren los mismos datos.

Solo me enfocaré en SQL Server desde que lo mencionaste. No veo ninguna razón para poner 'tbl' frente a una mesa. Simplemente puede mirar cualquier código tSQL y distinguir una tabla por cómo se usa. Nunca quisiera Select from stored_procedure.o Select from table(with_param)quisiera un UDF o Execute tblTableOrViewNameun procedimiento almacenado.

Las tablas pueden confundirse con una vista, pero cuando se trata de cómo se usan; no hay diferencia, entonces, ¿cuál es el punto? La notación húngara puede ahorrarle el tiempo de buscarlo en SSMS (¿debajo de la tabla o vistas?), Pero eso es todo.

Las variables pueden presentar un problema, pero deben declararse y, en realidad, ¿qué tan lejos de su declaración de declaración planea usar una variable? Desplazarse unas pocas líneas no debería ser un gran problema a menos que esté escribiendo procedimientos muy largos. Puede ser una buena idea dividir un poco el largo código.

Lo que describe es un dolor, pero la solución de notación húngara realmente no resuelve el problema. Puede mirar el código de otra persona y descubrir que el tipo de variable puede cambiar, lo que ahora requiere un cambio en el nombre de la variable. Solo una cosa más para olvidar. Y si uso un VarChar, de todas formas necesitará mirar la declaración de declaración para saber el tamaño. Los nombres descriptivos probablemente lo llevarán más lejos. @PayPeriodStartDate se explica más o menos.

Otra cosa para agregar es que, ¿qué abreviaturas usarías para un marco completo como .NET? Sí, es muy simple recordar que btnrepresenta un botón y txtrepresenta un cuadro de texto. Sin embargo, ¿qué tienes en mente para algo así StringBuilder? strbld? ¿Qué hay de CompositeWebControl? ¿Usas algo como esto:

CompositeWebControl comWCMyControl = new CompositeWebControl();

Una de las ineficiencias de la notación húngara fue que, al tener marcos cada vez más grandes, resultó no solo para agregar un beneficio adicional, sino también para agregar más complejidad a los desarrolladores, porque ahora tenían que aprender los prefijos no estándar cada vez más.

A mi modo de ver las cosas, la notación húngara es un truco para sortear un sistema de tipos insuficientemente poderoso. En los idiomas que le permiten definir sus propios tipos, es relativamente trivial crear un nuevo tipo que codifique el comportamiento que espera. En el discurso de Joel Spolsky sobre la notación húngara, da un ejemplo de su uso para detectar posibles ataques XSS al indicar que una variable o función es insegura (nosotros) o segura (s), pero que aún depende del programador para verificar visualmente. Si, en cambio, tiene un sistema de tipos extensible, puede crear dos tipos nuevos, UnsafeString y SafeString, y luego usarlos según corresponda. Como beneficio adicional, el tipo de codificación se convierte en:

SafeString encode(UnsafeString)

y la falta de acceso a los elementos internos de UnsafeString o el uso de algunas otras funciones de conversión se convierte en la única forma de pasar de UnsafeString a SafeString. Si todas sus funciones de salida solo toman instancias de SafeString, resulta imposible generar una cadena sin escape [mostrando travesuras con conversiones como StringToSafeString (someUnsafeString.ToString ())].

Debería ser obvio por qué permitir que el sistema de tipos verifique su código es superior a intentar hacerlo a mano, o tal vez ojo en este caso.

En un lenguaje como C, por supuesto, estás jodido porque un int es un int es un int, y no hay mucho que puedas hacer al respecto. Siempre puedes jugar juegos con estructuras, pero es discutible si eso es una mejora o no.

En cuanto a la otra interpretación de la notación húngara, el prefijo IE con el tipo de la variable, eso es simplemente estúpido y alienta prácticas perezosas como nombrar variables uivxwFoo en lugar de algo significativo como countOfPeople.

La notación húngara es casi completamente inútil en un lenguaje estáticamente escrito. Es una función IDE básica para mostrar el tipo de una variable colocando el mouse sobre ella o por otros medios; Además, puede ver cuál es el tipo mirando algunas líneas donde se declaró, si no hay inferencia de tipos. El punto principal de la inferencia de tipos es que no se repita el ruido del tipo en todas partes, por lo que la notación húngara generalmente se ve como algo malo en los idiomas con inferencia de tipos.

En lenguajes escritos dinámicamente, a veces puede ayudar, pero para mí parece unidiomático. Ya renunció a que sus funciones se restringieran a dominios / codicios exactos; Si todas sus variables se nombran con notación húngara, simplemente está reproduciendo lo que un sistema de tipos le hubiera dado. ¿Cómo expresas una variable polimórfica que puede ser un entero o una cadena en notación húngara? "IntStringX"? "IntOrStringX"? El único lugar en el que he usado la notación húngara fue en el código de ensamblaje, porque estaba tratando de recuperar lo que obtendría si tuviera un sistema de tipos, y fue lo primero que codifiqué.

De todos modos, no me importa cómo la gente nombra sus variables, el código probablemente seguirá siendo tan incomprensible. Los desarrolladores pierden demasiado tiempo en cosas como el estilo y los nombres de variables, y al final del día todavía obtienes un montón de bibliotecas con convenciones completamente diferentes en tu idioma. Estoy desarrollando un lenguaje simbólico (es decir, no basado en texto) donde no hay nombres de variables, solo identificadores únicos y nombres sugeridos para las variables (pero la mayoría de las variables aún no tienen un nombre sugerido porque simplemente no existe un nombre razonable para ellos); Al auditar código no confiable, no puede depender de nombres de variables.

Como es habitual en tal caso, publicaré una respuesta antes de leer las respuestas de otros participantes. 

Veo tres "errores" en su visión: 

1) Si desea conocer el tipo de una variable / parámetro / atributo / columna, puede pasar el mouse o hacer clic en él y se mostrará, en la mayoría de las IDE modernas. No sé qué herramientas estás usando, pero la última vez que me vi obligado a trabajar en un entorno que no proporcionaba esta función fue en el siglo XX, el idioma era COBOL, ¡Uy, no, era Fortran y mi jefe! No entendí por qué me fui. 

2 / Los tipos pueden cambiar durante el ciclo de desarrollo. Un número entero de 32 bits puede convertirse en un número entero de 64 bits en algún momento, por buenas razones que no se habían detectado al comienzo del proyecto. Entonces, renombrar intX en longX o dejarlo con un nombre que apunte al tipo incorrecto es mal karma. 

3) Lo que estás pidiendo es, de hecho, una redundancia. La redundancia no es un patrón o hábito de diseño muy bueno. Incluso los humanos son reacios a demasiada redundancia. Incluso los humanos son reacios a demasiada redundancia. 

Creo que tener una gran necesidad de húngaro es un síntoma .
Un síntoma de demasiadas variables globales ... o de tener funciones demasiado largas para ser mantenibles .

Si su definición variable no está a la vista, por lo general, tiene problemas.
Y si sus funciones no siguen una convención memorable , nuevamente, un gran problema.

Esa es ... la razón por la cual muchos lugares de trabajo lo eliminan, supongo.

Se originó en idiomas que lo necesitaban .
En tiempos de variables globales bonanza . (por falta de alternativas)
Nos sirvió bien.

El único uso real que tenemos para que hoy es el Joel Spolsky uno .
Para rastrear algunos atributos particulares de la variable, como su seguridad .

( por ejemplo, "¿La variable safeFoobartiene una luz verde para ser inyectada en una consulta SQL?
- Como se llama safe, sí")

Algunas otras respuestas hablaron sobre las funcionalidades del editor que ayudaron a ver el tipo de una variable al pasar el mouse sobre ella. En mi opinión, esos también son un poco problemáticos para la cordura del código . Creo que solo estaban destinados a la refactorización , como muchas otras características también (como el plegado de funciones) y no deberían usarse en el nuevo código.

Creo que los motivos para no usar la notación húngara han sido bien cubiertos por otros carteles. Estoy de acuerdo con sus comentarios

Con las bases de datos, uso la notación húngara para los objetos DDL que rara vez se usan en el código, pero que de lo contrario colisionarían en los espacios de nombres. Principalmente, esto se reduce a prefijos de índices y restricciones con nombre con su tipo (PK, UK, FK e IN). Use un método coherente para nombrar estos objetos y debería poder ejecutar algunas validaciones consultando los metadatos.

la razón por la que se evita es por los sistemas húngaros que violan DRY (el prefijo es exactamente el tipo que el compilador y (un buen) IDE pueden derivar)

prefijos OTOH húngaros de aplicaciones con el uso de la variable (es decir, scrxMouse es la coordenada del eje en la pantalla, puede ser un tipo int, corto, largo o incluso personalizado (typedefs incluso le permitirá cambiarlo fácilmente))

El malentendido de los sistemas es lo que destruyó al húngaro como mejor práctica

Digamos que tenemos un método como este (en C #):

int GetCustomerCount()
{
    // some code
}

Ahora en código lo llamamos así:

var intStuff = GetCustomerCount();
// lots of code that culminates in adding a customer
intStuff++;

El int no nos dice mucho. El mero hecho de que algo sea un int no nos dice qué contiene. Ahora supongamos, en cambio, lo llamamos así:

var customerCount = GetCustomerCount();
// lots of code that culminates in adding a customer
customerCount++;

Ahora podemos ver cuál es el propósito de la variable. ¿Importaría si supiéramos que es un int?

Sin embargo, el propósito original del húngaro era que hicieras algo como esto:

var cCustomers = GetCustomerCount();
// lots of code that culminates in adding a customer
cCustomers++;

Esto está bien siempre que sepas lo que significa c . Pero tendría que tener una tabla estándar de prefijos, y todos tendrían que conocerlos, y cualquier persona nueva tendría que aprenderlos para comprender su código. Mientras que customerCounto countOfCustomerses bastante obvio a primera vista.

El húngaro tenía algún propósito en VB antes de Option Strict Onexistir, porque en VB6 y antes (y en VB .NET con Option Strict Off) VB obligaría a los tipos, por lo que podría hacer esto:

Dim someText As String = "5"
customerCount = customerCount + someText

Esto es malo, pero el compilador no te lo diría. Entonces, si usaste húngaro, al menos tendrías algún indicador de lo que estaba sucediendo:

Dim strSomeText As String = "5"
intCustomerCount = intCustomerCount + strSomeText  // that doesn't look right!

En .NET, con escritura estática, esto no es necesario. Y el húngaro se usaba con demasiada frecuencia como sustituto del buen nombre. Olvídate del húngaro y elige buenos nombres.

Encontré muchos buenos argumentos en contra, pero uno que no vi: ergonomía.

En otros tiempos, cuando todo lo que tenía era string, int, bool y float, los caracteres sibf habrían sido suficientes. Pero con string + short, comienzan los problemas. ¿Usar el nombre completo para el prefijo o str_name para string? (Si bien los nombres son casi siempre cadenas, ¿no?) ¿Qué pasa con una clase de Street? Los nombres se hacen cada vez más largos, e incluso si usa CamelCase, es difícil saber dónde termina el prefijo de tipo y dónde comienza el nombre de la variable.

 BorderLayout boderLayoutInnerPanel = new BorderLayout ();
 panelInner.addLayout (borderLayoutInnerPanel);

De acuerdo, podría usar subrayados, si ya no los usa para otra cosa, o usar CamelCase si utilizó subrayados durante tanto tiempo:

 BorderLayout boderLayout_innerPanel = new BorderLayout ();
 panel_inner.addLayout (borderLayout_innerPanel);

 Border_layout boder_layoutInner_panel = new Border_layout ();
 panelInner.add_layout (border_layoutInner_panel);

Es monstruoso y si lo haces en consecuencia, tendrás

 for (int iI = 0; iI < iMax-1; ++iI)
     for (int iJ = iI; iJ < iMax; ++iMax) 
          int iCount += foo (iI, iJ); 

O terminará usando prefijos inútiles para casos triviales, como variables de bucle o count. ¿Cuándo usó recientemente un corto o un largo para un contador? Si hace excepciones, a menudo perderá tiempo, pensando en necesitar un prefijo o no.

Si tiene muchas variables, normalmente se agrupan en un navegador de objetos que forma parte de su IDE. Ahora, si el 40% comienza con i_ para int, y el 40% con s_ para cadena, y están ordenados alfabéticamente, es difícil encontrar la parte significativa del nombre.

El único lugar donde todavía uso regularmente sufijos húngaros o análogos es en contextos donde los mismos datos semánticos están presentes en dos formas diferentes, como la conversión de datos. Esto puede ser en casos donde hay múltiples unidades de medida, o donde hay múltiples formas (por ejemplo, Cadena "123" y entero 123).

Las razones dadas aquí para no usarlo me parecen convincentes para no imponer el húngaro a otros, pero solo un poco sugerente, para decidir sobre su propia práctica.

El código fuente de un programa es una interfaz de usuario por derecho propio, que muestra algoritmos y metadatos para el responsable del mantenimiento, y la redundancia en las interfaces de usuario es una virtud, no un pecado . Vea, por ejemplo, las imágenes en " El diseño de las cosas cotidianas ", y mire las puertas con la etiqueta "Empuje" que parece que las tira, y los grifos de cerveza que los operadores piratearon en los importantes controles del reactor nuclear porque de alguna manera "se ciernen sobre ellos en el IDE "no fue lo suficientemente bueno.

El "solo desplazarse en un IDE" no es una razón para no usar el húngaro, solo una razón para que algunas personas no lo encuentren útil. Su kilometraje puede diferir.

La idea de que el húngaro impone una carga de mantenimiento significativa cuando cambian los tipos de variables es una tontería: ¿con qué frecuencia cambia los tipos de variables? Además, renombrar variables es fácil:

Simplemente use el IDE para cambiar el nombre de todas las ocurrencias. -Gander, respondiendo a Goose

Si Hungarian realmente lo ayuda a asimilar rápidamente un fragmento de código y mantenerlo de manera confiable, úselo. Si no, no lo hagas. Si otras personas le dicen que está equivocado acerca de su propia experiencia, sugeriría que probablemente sean ellos los que cometieron un error.