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

101

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?

usuario29981
fuente
39
¿Qué idioma / IDE usas? En Visual Studio, no tiene que ir a la definición para conocer el tipo de variable, ya que el IDE se la proporciona. En los lenguajes donde los tipos no se aplican, como PHP, no necesita saber el tipo la mayor parte del tiempo (ya que puede asignar 0 o 1 a un booleano).
Arseni Mourzenko
10
@MainMa No estoy seguro de que sea una buena razón para no saber el tipo de valor en PHP.
Rei Miyasaka
29
"Cuando los proyectos se hacen extensos" ... no debería importar. Solo debería haber un pequeño número de variables en el alcance en cualquier momento: un puñado de variables de clase y otro puñado de argumentos de método. Si no puede mantenerlos rectos, entonces la clase es demasiado grande o el método es demasiado largo. La notación húngara se inventó para la programación de Windows C, básicamente como una solución alternativa para la horrible API de Windows. Nunca se sugirió o quiso nada similar para el desarrollo de Unix.
Kevin Cline
20
¿Cuál es el beneficio de no usar la notación húngara? "No ser odiado por tus compañeros de trabajo" viene a la mente ...
Sean Patrick Floyd
25
adjNunNotation nNotation vIs adjHard prepTo vRead.
dan04

Respuestas:

148

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 ...
Marjan Venema
fuente
99
@ Surfer513: En realidad, prefiero sufijos al nombrar controles. Para mí es mucho más interesante encontrar todos los controles que tratan un tema / aspecto específico que encontrar todos los controles de edición ... Cuando quiero encontrar el control donde el usuario puede escribir el nombre de un cliente, comenzaré a buscar cliente en lugar de txt, porque podría no ser un txt (editar) sino una nota o un richedit o un ... Incluso podría ser un cuadro combinado para permitir encontrarlo en nombres de clientes ingresados ​​previamente ...
Marjan Venema
8
@ Surfer513: Y hoy en día tiendo a usar sufijos solo al distinguir entre dos controles que se ocupan de lo mismo. Por ejemplo, la etiqueta y la edición para el nombre del cliente. Y a menudo los sufijos no están relacionados con el tipo de control, sino con su propósito: ClientCaption y ClientInput, por ejemplo.
Marjan Venema
3
También vale la pena señalar que intellisense en VS 2010 le permite buscar el nombre completo , no solo el comienzo. Si nombra su control "firstNameTextBox" y escribe "textb", encontrará su control y lo listará.
Adam Robinson
44
'... la versión maltratada se evita como la placa ...', es decir, ¿se evita un poco menos que el sarro y la gingivitis? ;-)
Ben Mosher
44
@ Marjan: Por supuesto, un compilador podría haber captado esto. Si cada unidad está representada por un tipo, entonces no puede pasar accidentalmente una por otra. Aquí, si tiene a AbsoluteXTypey a RelativeYType, entonces no podría pasar por error una coordenada relativa Y para una X absoluta. Prefiero que las variables que representan entidades incompatibles sean de tipos incompatibles, en lugar de tener prefijos incompatibles. El compilador no se preocupa por los prefijos (o sufijos).
Matthieu M.
74

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.

revs usuario7519
fuente
2
"Qué sucede cuando cambias tu inta un tipo diferente como long..." Simple: <sarcasm> No cambies el nombre porque no se sabe en cuántos lugares se ondulará el cambio. </sarcasm> Entonces ahora tienes una variable cuyo El nombre húngaro entra en conflicto con su implementación. No hay absolutamente ninguna manera de saber cuán generalizados serán los efectos de cambiar el nombre si la variable / función tiene visibilidad pública.
David Hammen
2
El artículo vinculado es fantástico y vale la pena leerlo. +1
Marty Pitt
66
@David solo mira la API de Win32 que está plagada de variables, parámetros e incluso nombres de métodos que usan la notación húngara (que es un requisito en MS) indican un valor de 8 bits o 16 bits cuando en realidad todos han sido de 32 bits valores desde la introducción de Windows 95 en 1994 (hace casi 17 años).
Jwent
2
@Secure: Yo diría que eso es lo que deberían estar haciendo las pruebas automatizadas. No programadores.
Joel
2
@Secure tal vez no esté en una aplicación interna, pero si mantiene una API pública como la API de Windows, es un problema importante.
Jwenting
51

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.

Falcon
fuente
1
Esta debería ser la respuesta correcta. Es muy bueno. +1
Saeed Neamati
Eres demasiado amable, Saeed. Valoro su apreciación, pero las otras respuestas a esta pregunta también son realmente buenas.
Falcon
11
Votaron por una sola oración: " 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 " . Esta es la razón # 1 para evitar la notación húngara.
Daniel Pryden
19

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.

tsundoku
fuente
44
+1 para obtener información muy interesante allí. Uso 'sp' como mi prefijo de proceso almacenado, no 'sp_'. Pero de todos modos, eso es definitivamente un hecho muy muy interesante y una razón concreta para no usar 'sp_' como prefijo de proceso almacenado.
2
+1 Nunca supe esto, y cuando comencé a trabajar en SQL Server, todos los SP en mi lugar de trabajo tenían un prefijo, sp_así que me quedé con la convención.
Michael
Gran punto, pero nada que ver con esta pregunta (usando sq y no _sp). Es como dejar de lado el nombre del esquema para los objetos que no están en el esquema predeterminado.
JeffO
1
Para los procedimientos almacenados por el usuario, usé convencionalmente 'usp_'. Esto sirvió para evitar el problema mencionado Y distinguir para el lector si el sproc era sistema o usuario.
Paraguas
15

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.

Wayne M
fuente
13

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.

JeffO
fuente
2
@Surfer: una clave primaria es diferente porque "PK" no es el tipo; "PK_TableName" dice "esta es la clave principal para TableName", no "este es un TableName de tipo PK". En cuanto al resto ... no parece que realmente estés escuchando los argumentos aquí. Deje de usar esta práctica detestable que hasta el día de hoy persiste en reducir la calidad colectiva de todo el código.
Aaronaught
2
@Aaronaught, está especificando un aspecto de la notación húngara ( en.wikipedia.org/wiki/Hungarian_notation ). No es solo el tipo, sino también el uso previsto. Por lo tanto, el prefijo 'pk' para una clave primaria es, de hecho, la notación húngara. Estoy escuchando argumentos aquí, pero hay excepciones (como la situación clave principal) donde parece que HN es beneficioso. Tal vez tal vez no. Todavía estoy tratando de entender qué hacer y qué no hacer para todos los escenarios. Hoy he aprendido bastante sobre eso y ha provocado un gran pensamiento.
3
@Surfer: Eso simplemente no es correcto. La notación húngara describe el tipo (versión incorrecta) o un uso particular del tipo (versión menos incorrecta). PK tampoco es, no es simplemente describir algo sobre el tipo, es describir un comportamiento . Cuando estoy hablando de, digamos, una edad, es completamente poco interesante que sea un número entero, pero cuando se habla de una restricción de la base de datos, "clave principal para la tabla X" es exactamente lo que importa.
Aaronaught
44
Me gusta tu penúltimo párrafo. La razón de mi empresa para usar la notación húngara es "nos permite ver rápidamente qué variables son globales y cuáles no". Y luego nos fijamos en las declaraciones de variables y hay 300 variables por archivo, algunas m * para modular (global), algunas v * para local AUNQUE ESTÁN DECLARADAS A NIVEL MODULAR. "Oh, eso es porque están destinados a ser utilizados como locales, no como modulares". facepalm
corsiKa
3
@Aaronaught: en mi proyecto actual, estamos usando nombres de tablas con el prefijo tbl_ . Si bien no soy un gran admirador de esta práctica, no veo cómo esto "reduce la calidad colectiva de todo el código" . ¿Puedes quizás dar un ejemplo?
Treb
6

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.

Saeed Neamati
fuente
6

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.

Orclev
fuente
¿Cómo se declararía un tipo .NET o Java para describir " int[]que puede modificarse libremente pero nunca compartirse" o " int[]que puede compartirse libremente solo entre cosas que nunca lo modificarán"? Si un int[]campo fooencapsula los valores, ¿se {1,2,3}puede encapsular {2,2,3}sin saber qué "tipo" int[]representa? Creo que Java y .NET habrían sido mucho mejores si, en ausencia de soporte de sistema de tipos, al menos hubieran adoptado una convención de nomenclatura para distinguir esos tipos.
supercat
4

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.

Longpoke
fuente
¡También es bastante inútil para la mayoría de los idiomas escritos dinámicamente!
James Anderson el
2
para IDEs es incluso peor que para la codificación manual, ya que significa que la finalización del código se ralentiza drásticamente. Si tiene 100 variables enteras, escribir int <alt-space> (por ejemplo) muestra 100 elementos para desplazarse. Si el que necesita es intVeryLongVariableName, la finalización de su código se vuelve problemática. Sin húngaro, simplemente escribirías muy <alt-space> y solo tendrías 1 o 2 opciones.
Jwent
3

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. 

Oqaqiq
fuente
Entiendo el IDE avanzado / moderno, y estoy completamente de acuerdo con usted. ¿Pero qué pasa con el diseño de la base de datos? Digamos que tiene una columna o un parámetro de procedimiento almacenado. El truco sobre el truco realmente no funciona con ese tipo de cosas. Tendría que mirar la tabla / definición de proceso almacenado. Que haces por eso
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 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.

revs ZJR
fuente
2

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.

BillThor
fuente
A menudo encuentro que este es el caso cuando tengo una tabla de identificadores. Si tengo TABLE SomeStringById(int somestringId, varchar somestring)el índice, lógicamente también lo sería, SomeStringByIdpero eso causa una colisión. Entonces lo llamo idx_SomeStringById. Luego, para seguir su ejemplo, lo haré idx_SomeStringByValuesolo porque es una tontería tener idx_uno y no el otro.
corsiKa
1

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

monstruo de trinquete
fuente
2
Tengo que estar en desacuerdo: lo que destruyó al húngaro como una "mejor práctica" es que nunca estuvo cerca de la mejor (o incluso buena) práctica.
Jerry Coffin
2
@haylem: He visto los artículos y el artículo original de Simonyi, y leí el código. En todos los sentidos, es una mala idea que nunca debería haber visto la luz del día.
Jerry Coffin
1
No necesariamente viola DRY en un lenguaje dinámico; Es unidiomático. SECO no es necesariamente siempre bueno; Ej: C macros.
Longpoke
3
En mi opinión, lo que "destruyó" al húngaro es el hecho de que incluso la "intención" no es útil en comparación con el uso de nombres descriptivos , aunque para ser justos cuando se creó el húngaro no hubo un movimiento para tener un código legible ...
Wayne Molina
1
@Wayne M: "nombres descriptivos" es fácil de decir cuando los compiladores esencialmente le permitirán usar un ensayo para un nombre variable. Cuando la longitud de los nombres de identificador se limita verdaderamente a un valor bajo, bastante arbitraria (creo que un límite común era ocho o diez caracteres no que hace extremadamente larga; me parece recordar que Borland Turbo C 2 hasta tenía una opción de configuración para el longitud máxima de un nombre de identificador!), codificar información útil en un nombre fue un poco más complicado ...
un CVn
1

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.

Kyralessa
fuente
1

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.

usuario desconocido
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 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.

Ed Staub
fuente