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

94

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 para ver qué tipo es. Cuando un proyecto se vuelve extenso, es bueno poder ver una variable con el prefijo 'bool' y saber que está buscando verdadero / falso en lugar de un 0/1 valor.

También hago mucho trabajo en SQL Server. Prefijo mis procedimientos almacenados con 'sp' y mis tablas con 'tbl', por no 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 evitarlo. 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 plaga?

    
pregunta 5 revs, 3 users 62%user29981 21.08.2011 - 22:01
fuente

16 respuestas

141

Debido a su intención original (consulte enlace y enlace ) se ha malentendido y se ha usado (ab) para recordar qué tipo es una variable cuando el idioma que usan no está tipificado de forma estática. En cualquier lenguaje tipado estáticamente, no necesita el balasto agregado de prefijos para decirle qué tipo de variable es. En muchos lenguajes de script no tipificados puede ayudar, pero a menudo se ha abusado hasta el punto de volverse totalmente inmanejable. Desafortunadamente, en lugar de volver a la intención original de la notación húngara, la gente acaba de convertirse en una de esas cosas "malvadas" que debes evitar.

La notación húngara en breve estaba destinada a prefijar variables con algunas semánticas. Por ejemplo, si tiene coordenadas de pantalla (izquierda, arriba, derecha, abajo), prefijaría las variables con posiciones absolutas de pantalla con " abs " y las variables con posiciones relativas a una ventana con " rel ". De esa manera, sería obvio para cualquier lector que 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 se evita como la plaga porque

  • complica el nombramiento. Cuando (ab) use la notación húngara, siempre habrá discusiones sobre qué tan específicos deben ser los prefijos. Por ejemplo: listboxXYZ o MyParticularFlavourListBoxXYZ .
  • hace que los nombres de las variables sean más largos sin facilitar la comprensión de para qué sirve la variable.
  • es una especie de derrota del 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 ui un entero sin signo? una interfaz contada sin referencia? ¿algo que ver con las interfaces de usuario? Y esas cosas pueden hacerse largas . 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 se confunden.
  • se desactualiza rápidamente. Cuando cambias el tipo de una variable, la gente invariablemente (lol) se olvida de actualizar el prefijo para reflejar el cambio, o no lo actualiza deliberadamente porque eso provocaría cambios de código en todos los lugares donde se usa la var ...
  • se complica hablando 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 el código de discusión, 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 ...
respondido por el Marjan Venema 17.04.2012 - 16:38
fuente
71

La notación húngara es un antipatrón de denominación en los entornos de programación de hoy en día y forma de Tautology .

Repite inútilmente la información sin beneficios y gastos adicionales de mantenimiento. ¿Qué sucede cuando cambia su int a un tipo diferente como 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 equivocadas, lo que es peor que si no hubiera duplicado El tipo en el nombre.

Viola el principio DRY. Si tiene que prefijar las tablas de su base de datos con una abreviatura para recordarle que se trata de una tabla, entonces definitivamente no está nombrando sus tablas de forma semánticamente descriptiva. Lo mismo ocurre con cualquier otra cosa con la que estés haciendo esto. Es solo teclear más y trabajar sin ningún beneficio o beneficio con un entorno de desarrollo moderno.

    
respondido por el Jarrod Roberson 21.08.2011 - 18:48
fuente
50

Wikipedia tiene una lista de ventajas y desventajas de la notación húngara y, por lo tanto, puede proporcionar la respuesta más completa. a esta pregunta Las opinons 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 comprobación de tipo. Los compiladores de idiomas que proporcionan verificación de tipos aseguran que el uso de una variable sea coherente con su tipo automáticamente; los controles a ojo son redundantes y están sujetos a error humano.

  •   
  • Todos los entornos de desarrollo integrado modernos muestran tipos de variables a pedido y marcan automáticamente las operaciones que usan tipos incompatibles, lo que hace que la notación sea en gran parte 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 LastName de tipo varchar(30) que es parte de clave principal de la mesa.

  •   
  • Puede ocasionar inconsistencia cuando se modifica o se transfiere el código. Si se cambia el tipo de una variable, o la decoración en el 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 estándar WPARAM y el parámetro formal que acompaña a wParam en muchas declaraciones de funciones del sistema 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 tipo de 64 bits en arquitecturas de palabras de 64 bits en versiones posteriores del sistema operativo mientras se conserva 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 plataforma a plataforma, se asume que "w" significa 16 bits en esos entornos diferentes.

  •   
  • La mayoría de las veces, saber 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 de usar editores de código con múltiples funciones que admiten la terminación de nombres de variables, ya que el programador debe ingresar primero el especificador de tipo completo.

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

  •   
  • La información de tipo adicional puede reemplazar de manera insuficiente los nombres más descriptivos. P.ej. sDatabase no le dice al lector qué es. databaseName podría ser un nombre más descriptivo.

  •   
  • Cuando los nombres son lo suficientemente descriptivos, la información de tipo adicional puede ser redundante. P.ej. firstName es probablemente una cadena. Por lo tanto, nombrarlo sFirstName solo 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 de letra estoy tratando y quiero un lenguaje limpio en mi modelo de dominio, pero escribo principalmente en idiomas tipificados de forma estática y fuerte.

    
respondido por el Falcon 22.08.2011 - 15:36
fuente
19

Como problema específico de MS SQL Server:

  

Todos los procedimientos almacenados con el prefijo 'sp_' se buscan primero en   La base de datos maestra en lugar de la que se crea. Esto   causar un retraso en el procedimiento almacenado que se está ejecutando.

    
respondido por el tsundoku 21.08.2011 - 19:44
fuente
15

El principal beneficio de no usar húngaro es el hecho de que te obliga a usar nombres significativos . Si está nombrando las variables correctamente, debe saber de inmediato qué tipo es o poder deducirlo con bastante rapidez en cualquier sistema bien diseñado. Si necesita confiar en los prefijos str o bln o, lo que es peor, en todos los prefijos obj para saber qué tipo de variable es, diría que indica un problema de denominación: nombres de variables incorrectos en general o demasiado genéricos para transmitir significado.

Irónicamente, a partir de la experiencia personal, el escenario principal que he visto usar en húngaro es la programación de "culto a la carga" (es decir, otro código lo usa, así que continuemos usándolo solo porque) o en VB.NET para solucionar el problema el lenguaje no distingue entre mayúsculas y minúsculas (por ejemplo, Person oPerson = new Person porque no puede usar Person person = new Person y Person p = new Person es demasiado vago); También he visto el prefijo "the" o "my" en su lugar (como en Person thePerson = new Person o el más feo Person myPerson = new Person ), en ese caso particular.

Agregaré la única vez que uso el húngaro que suele ser para los controles de ASP.NET y eso es realmente una cuestión de elección. Me parece muy feo escribir TextBoxCustomerName o CustomerNameTextBox en comparación con el txtCustomerName más simple, pero incluso eso se siente "sucio". Creo que se debe usar algún tipo de convenio de denominación para los controles, ya que puede haber varios controles que muestren los mismos datos.

    
respondido por el Wayne M 22.08.2011 - 15:15
fuente
13

Me centraré en SQL Server desde que lo mencionaste. No veo ninguna razón para poner 'tbl' delante de una mesa. Simplemente puede mirar cualquier código tSQL y distinguir una tabla por la forma en que se usa. Nunca haría Select from stored_procedure. o Select from table(with_param) como lo haría con un UDF o Execute tblTableOrViewName como un procedimiento almacenado.

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

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

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

    
respondido por el JeffO 21.08.2011 - 19:11
fuente
6

Otra cosa para agregar es que, ¿qué abreviaturas usaría para un marco completo como .NET? Sí, es tan fácil de recordar que btn representa un botón y txt representa un cuadro de texto. Sin embargo, ¿qué tienes en mente para algo como StringBuilder ? %código%? ¿Qué hay de strbld ? ¿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, demostró no solo agregar un beneficio adicional, sino también una mayor complejidad para los desarrolladores, porque ahora tenían que aprender los prefijos no estándar más y más.

    
respondido por el Saeed Neamati 21.08.2011 - 22:57
fuente
5

En mi forma 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 está esperando. En la perorata de Joel Spolsky sobre la notación húngara, da un ejemplo de cómo usarlo 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 realizar una verificación visual. 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, a menos que acceda a las partes internas de UnsafeString o utilice otras funciones de conversión, se convierte en la única forma de pasar de un UnsafeString a un SafeString. Si todas sus funciones de salida solo toman instancias de SafeString, resulta imposible generar una cadena sin escape [descubriendo shenanigans con conversiones como StringToSafeString (someUnsafeString.ToString ())].

Debería ser obvio por qué permitir que el sistema de texto compruebe la integridad de 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 equivocado al decir que 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, I.E. prefijar 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.

    
respondido por el Orclev 22.08.2011 - 20:17
fuente
4

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

En idiomas tipificados dinámicamente, puede ayudar algunas veces, pero a mí me parece unidiomático. Ya abandonaste tus funciones restringidas a dominios / codominios exactos; Si todas sus variables están nombradas con notación húngara, simplemente están reproduciendo lo que un sistema de tipo le hubiera dado. ¿Cómo se expresa una variable polimórfica que puede ser un número 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 la primera cosa que he codificado.

De todos modos, no me importa lo que la gente nombre de sus variables, el código probablemente seguirá siendo igual de 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) en el que no hay nombres de variables, solo identificadores únicos y nombres sugeridos para variables (pero la mayoría de las variables aún no tienen un nombre sugerido porque simplemente no existe un nombre razonable para ellos); cuando audita un código que no es de confianza, no puede depender de los nombres de las variables.

    
respondido por el Longpoke 21.08.2011 - 22:48
fuente
3

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

Veo tres "errores" en tu visión:

1) Si desea saber el tipo de variable / parámetro / atributo / columna, puede mover el mouse o hacer clic en él y se mostrará, en la mayoría de los IDE modernos. No sé qué herramientas está utilizando, pero la última vez que me vi obligado a trabajar en un entorno que no proporcionaba esta función era en el siglo XX, el lenguaje era COBOL, oops, no era Fortran y mi jefe No entendí por qué me fui.

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

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

    
respondido por el Oqaqiq 22.08.2011 - 01:38
fuente
3

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 poder mantenerlas .

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

Esa es ... casi la razón por la que muchos lugares de trabajo lo echan a perder, supongo.

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

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

( por ejemplo "¿La variable safeFoobar tiene 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 variable a medida que se desplaza sobre ella. En mi opinión, esos también son un poco problemáticos para la cordura del código . Creo que solo estaban diseñados para refactorizar , como muchas otras características también (como la función de plegado) y no deberían usarse en el nuevo código.

    
respondido por el ZJR 23.08.2011 - 05:55
fuente
2

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

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

    
respondido por el BillThor 21.08.2011 - 22:45
fuente
1

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

aplicaciones húngaras O.T.O.H. prefijos con el uso de la variable (es decir, scrxMouse es una coordenada ax en la pantalla, esto puede ser un tipo int, corto, largo o incluso un tipo personalizado (typedefs incluso le permitirá cambiarlo fácilmente))

la mala interpretación de los sistemas es lo que destruyó el húngaro como una buena práctica

    
respondido por el ratchet freak 21.08.2011 - 18:31
fuente
1

Supongamos 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 sabemos que es un int?

El propósito original del húngaro, sin embargo, era que hagas 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 customerCount o countOfCustomers es bastante obvio a primera vista.

El húngaro tenía algún propósito en VB antes de que existiera Option Strict On , porque en VB6 y anteriores (y en VB .NET con Option Strict Off ) VB coaccionaría 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 usas 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 de un buen nombramiento. Olvídate del húngaro y elige buenos nombres en su lugar.

    
respondido por el Kyralessa 22.08.2011 - 20:05
fuente
1

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

En tiempos anteriores, cuando todo lo que tenías 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 la cadena? (Mientras que los nombres son casi siempre cadenas, ¿no?) ¿Qué es una clase de calle? Los nombres se vuelven más y más largos, e incluso si usa CamelCase, es difícil saber dónde termina el tipo de prefijo y dónde comienza el nombre de la variable.

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

De acuerdo, puede usar subrayados, si no los usa para otra cosa, o usar CamelCase si ha usado subrayados por mucho 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 bien, terminará utilizando prefijos inútiles para casos triviales, como variables de bucle o count . ¿Cuándo recientemente usaste 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.

    
respondido por el user unknown 23.08.2011 - 01:30
fuente
1

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 ocurrir en los casos en que hay varias unidades de medida o en varias formas (por ejemplo, String "123" y entero 123).

Encuentro que las razones que se dan aquí para no usarlas son convincentes para no imponer el húngaro en los demás, sino solo ligeramente sugestivas, para decidir sobre su propia práctica.

El código fuente de un programa es una interfaz de usuario por derecho propio, mostrando algoritmos y metadatos al mantenedor, 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 etiquetadas como "Empujar" parece que los jala, y en los grifos de cerveza, los operadores piratearon los importantes controles del reactor nuclear porque, de alguna manera, "flotar sobre ellos en el IDE" no era lo suficientemente bueno.

El "solo hover en un IDE" no es una razón para no usar húngaro, solo una razón para algunas personas puede que no le resulte ú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, cambiar el nombre de las variables es fácil:

  

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

Si Hungarian realmente te ayuda a asimilar rápidamente un trozo de código y mantenerlo de manera confiable, úsalo. Si no, no lo hagas. Si otras personas te dicen que estás equivocado acerca de tu propia experiencia, sugiero que probablemente sean los que están equivocados.

    
respondido por el Ed Staub 26.08.2011 - 20:03
fuente

Lea otras preguntas en las etiquetas