¿Por qué no debería utilizar la “notación húngara”?

Question

Sé a qué se refiere el húngaro: dar información sobre una variable, parámetro o tipo como prefijo de su nombre.Todo el mundo parece estar furiosamente en contra, aunque en algunos casos parece una buena idea.Si siento que se está impartiendo información útil, ¿por qué no debería ponerla allí donde esté disponible?

Ver también: ¿La gente utiliza las convenciones de nomenclatura húngaras en el mundo real?

Answer 1

La mayoría de la gente utiliza la notación húngara de forma incorrecta y obtiene resultados incorrectos.

Lea este excelente artículo de Joel Spolsky: Hacer que el código incorrecto parezca incorrecto.

En resumen, notación húngara donde antepones los nombres de tus variables con sus type (cadena) (Sistemas húngaro) es malo porque es inútil.

Notación húngara tal como fue concebida por su autor, donde se antepone el nombre de la variable con su kind (usando el ejemplo de Joel:cadena segura o cadena insegura), las llamadas aplicaciones húngaras tienen sus usos y siguen siendo valiosas.

Answer 2

vEl uso de la notación húngara adj dificulta la lectura del código n.

Answer 3

Joel está equivocado y he aquí por qué.

Esa información de "aplicación" de la que está hablando. debe codificarse en el sistema de tipos.No debe depender de invertir los nombres de las variables para asegurarse de no pasar datos inseguros a funciones que requieren datos seguros.Deberías convertirlo en un error de tipo, para que sea imposible para hacerlo.Cualquier dato no seguro debe tener un tipo marcado como no seguro, de modo que simplemente no pueda pasarse a una función segura.Para convertir de inseguro a seguro debería requerirse un procesamiento con algún tipo de función de desinfección.

Muchas de las cosas de las que Joel habla como "clases" no son clases;son, de hecho, tipos.

Sin embargo, lo que falta en la mayoría de los lenguajes es un sistema de tipos que sea lo suficientemente expresivo como para imponer este tipo de distinciones.Por ejemplo, si C tuviera una especie de "typedef fuerte" (donde el nombre typedef tuviera todas las operaciones del tipo base, pero no fuera convertible a él), entonces muchos de estos problemas desaparecerían.Por ejemplo, si pudieras decir, strong typedef std::string unsafe_string; para introducir un nuevo tipo unsafe_string que no se pudo convertir a std::string (y por lo tanto podría participar en la resolución de sobrecarga, etc.etc.) entonces no necesitaríamos prefijos tontos.

Entonces, la afirmación central de que el húngaro es para cosas que no son tipos es errónea.Se utiliza para información de tipo.Ciertamente, información de tipo más rica que la información de tipo C tradicional;es información de tipo que codifica algún tipo de detalle semántico para indicar el propósito de los objetos.Pero sigue siendo información de tipos, y la solución adecuada siempre ha sido codificarla en el sistema de tipos.Codificarlo en el sistema de tipos es de lejos la mejor manera de obtener una validación y aplicación adecuadas de las reglas.Los nombres de las variables simplemente no son suficientes.

En otras palabras, el objetivo no debe ser "hacer que el código incorrecto parezca incorrecto para el desarrollador".Debería ser "hacer que el código incorrecto parezca incorrecto". al compilador".

Answer 4

Creo que satura enormemente el código fuente.

Tampoco aporta mucho en un lenguaje fuertemente tipado.Si realiza algún tipo de tontería que no coincide con los tipos, el compilador se lo informará.

Answer 5

La notación húngara sólo tiene sentido en los idiomas sin tipos definidos por el usuario.En un lenguaje funcional o OO moderno, codificaría información sobre el "tipo" de valor en el tipo de datos o clase en lugar de en el nombre de la variable.

Referencia de varias respuestas. Artículo de Joel.Sin embargo, tenga en cuenta que su ejemplo está en VBScript, que no admitía clases definidas por el usuario (al menos durante mucho tiempo).En un lenguaje con tipos definidos por el usuario, resolvería el mismo problema creando un tipo HtmlEncodedString y luego dejando que el método Write acepte solo eso.En un lenguaje escrito estáticamente, el compilador detectará cualquier error de codificación; en un lenguaje escrito dinámicamente, obtendrá una excepción de tiempo de ejecución, pero en cualquier caso, estará protegido contra la escritura de cadenas no codificadas.Las notaciones húngaras simplemente convierten al programador en un verificador de tipos humano, siendo el tipo de trabajo que normalmente se realiza mejor mediante software.

Joel distingue entre "sistemas húngaros" y "aplicaciones húngaras", donde "sistemas húngaros" codifica los tipos integrados como int, float, etc., y "aplicaciones húngaras" codifica "tipos", que es metainformación de nivel superior. Acerca de las variables más allá del tipo de máquina. En un lenguaje funcional moderno o orientado a objetos se pueden crear tipos definidos por el usuario, por lo que no hay distinción entre tipo y "tipo" en este sentido (ambos pueden representarse mediante el sistema de tipos) y "aplicaciones". El húngaro es tan redundante como el húngaro "sistemas".

Entonces para responder a tu pregunta: Sistemas húngaro solo sería útil en un lenguaje inseguro y débilmente escrito donde, por ejemplo.asignar un valor flotante a una variable int bloqueará el sistema.La notación húngara se inventó específicamente en los años sesenta para su uso en BCPL, un lenguaje de bastante bajo nivel que no realizaba ninguna verificación de tipos.No creo que ningún lenguaje de uso general tenga este problema hoy en día, pero la notación sobrevivió como una especie de programación de culto de carga.

aplicaciones húngaras tendrá sentido si está trabajando con un lenguaje sin tipos definidos por el usuario, como VBScript heredado o versiones anteriores de VB.Quizás también las primeras versiones de Perl y PHP.Una vez más, usarlo en un lenguaje moderno es puro culto al cargo.

En cualquier otro idioma, el húngaro es simplemente feo, redundante y frágil.Repite información ya conocida del sistema de tipos, y no deberías repetirte.Utilice un nombre descriptivo para la variable que describe la intención de esta instancia específica del tipo.Utilice el sistema de tipos para codificar invariantes y metainformación sobre "tipos" o "clases" de variables, es decir.tipos.

El objetivo general del artículo de Joel (hacer que el código incorrecto parezca incorrecto) es un muy buen principio.Sin embargo, una protección aún mejor contra errores es, cuando sea posible, hacer que el compilador detecte automáticamente el código incorrecto.

Answer 6

Siempre uso la notación húngara para todos mis proyectos.Lo encuentro realmente útil cuando trato con cientos de nombres de identificadores diferentes.

Por ejemplo, cuando llamo a una función que requiere una cadena, puedo escribir 's' y presionar control-espacio y mi IDE me mostrará exactamente los nombres de las variables con el prefijo 's'.

Otra ventaja es que cuando prefijo u para entradas sin firmar y i para entradas firmadas, inmediatamente veo dónde estoy mezclando firmadas y sin firmar de maneras potencialmente peligrosas.

No puedo recordar la cantidad de veces que en una enorme base de código de 75000 líneas, se causaron errores (por mí y por otros también) debido a que se nombraban las variables locales de la misma manera que las variables miembro existentes de esa clase.Desde entonces, siempre antepongo a los miembros el prefijo 'm_'.

Es una cuestión de gusto y experiencia.No lo descartes hasta que lo hayas probado.

Answer 7

Estás olvidando la razón número uno para incluir esta información.No tiene nada que ver contigo, el programador.Tiene todo que ver con la persona que viene 2 o 3 años después de dejar la empresa y que tiene que leer esas cosas.

Sí, un IDE identificará rápidamente los tipos por usted.Sin embargo, cuando lees lotes largos de código de 'reglas de negocios', es bueno no tener que detenerte en cada variable para descubrir de qué tipo es.Cuando veo cosas como strUserID, intProduct o guiProductID, se convierte en mucho tiempo de "incremento" más fácil.

Estoy de acuerdo en que MS fue demasiado lejos con algunas de sus convenciones de nomenclatura; lo clasifico en la pila de "algo demasiado bueno".

Las convenciones de nomenclatura son buenas, siempre que las cumplas.Revisé suficiente código antiguo que me hizo volver constantemente a mirar las definiciones de tantas variables con nombres similares que presioné "carcasa de camello" (como se llamaba en un trabajo anterior).En este momento estoy en un trabajo que tiene miles de líneas de código ASP clásico completamente sin comentar con VBScript y es una pesadilla tratar de resolver las cosas.

Answer 8

Agregar caracteres crípticos al principio de cada nombre de variable es innecesario y muestra que el nombre de la variable por sí solo no es lo suficientemente descriptivo.La mayoría de los lenguajes requieren el tipo de variable en la declaración de todos modos, por lo que la información ya está disponible.

También existe la situación en la que, durante el mantenimiento, es necesario cambiar un tipo de variable.Ejemplo:Si una variable declarada como "uint_16 u16foo" necesita convertirse en 64 bits sin firmar, sucederá una de dos cosas:

1. Revisará y cambiará el nombre de cada variable (asegurándose de no incluir ninguna variable no relacionada con el mismo nombre), o
2. Simplemente cambie el tipo y no cambie el nombre, lo que sólo causará confusión.

Answer 9

Joel Spolsky escribió una buena publicación en el blog sobre esto.http://www.joelonsoftware.com/articles/Wrong.htmlBásicamente, todo se reduce a no hacer que su código sea más difícil de leer cuando un IDE decente le dirá que desea escribir la variable si no puede recordarlo.Además, si su código está lo suficientemente compartimentado, no tendrá que recordar qué variable se declaró tres páginas arriba.

Answer 10

¿No es el alcance más importante que el tipo en estos días?

* l for local
* a for argument
* m for member
* g for global
* etc

Con las técnicas modernas de refactorización de código antiguo, buscar y reemplazar un símbolo porque cambió su tipo es tedioso, el compilador detectará los cambios de tipo, pero a menudo no detectará el uso incorrecto del alcance; las convenciones de nomenclatura sensatas ayudan aquí.

Answer 11

No hay ninguna razón por la que no debas hacer correcto uso de la notación húngara.Su impopularidad se debe a una larga reacción contra el mal uso de notación húngara, especialmente en las API de Windows.

En los viejos tiempos, antes de que existiera algo parecido a un IDE para DOS (lo más probable es que no tuviera suficiente memoria libre para ejecutar el compilador en Windows, por lo que su desarrollo se realizaba en DOS), no recibía ninguna ayuda de pasando el mouse sobre el nombre de una variable.(Suponiendo que tuviera un mouse). Lo que sí tuvo que enfrentar fueron funciones de devolución de llamada de eventos en las que todo se le pasó como int de 16 bits (PALABRA) o int de 32 bits (PALABRA LARGA).Luego tenías que convertir esos parámetros a los tipos apropiados para el tipo de evento dado.De hecho, gran parte de la API prácticamente no tenía tipos.

El resultado, una API con nombres de parámetros como estos:

LRESULT CALLBACK WindowProc(HWND hwnd,
                            UINT uMsg,
                            WPARAM wParam,
                            LPARAM lParam);

Tenga en cuenta que los nombres wParam y lParam, aunque son bastante horribles, en realidad no son peores que nombrarlos param1 y param2.

Para empeorar las cosas, Windows 3.0/3.1 tenía dos tipos de punteros, cercanos y lejanos.Entonces, por ejemplo, el valor de retorno de la función de administración de memoria LocalLock era un PVOID, pero el valor de retorno de GlobalLock era un LPVOID (con la 'L' larga).Esa horrible notación luego se extendió de modo que yoong pagla cadena ointer tenía el prefijo lp, para distinguirlo de una cadena que simplemente había sido mallocada.

No sorprende que haya habido una reacción violenta contra este tipo de cosas.

Answer 12

La notación húngara puede ser útil en idiomas sin verificación de tipos en tiempo de compilación, ya que permitiría al desarrollador recordar rápidamente cómo se usa la variable en particular.No hace nada por el rendimiento o el comportamiento.Se supone que mejora la legibilidad del código y es principalmente una cuestión de gusto y estilo de codificación.Precisamente por esta razón es criticado por muchos desarrolladores: no todo el mundo tiene el mismo cableado cerebral.

Para los lenguajes de verificación de tipos en tiempo de compilación, es prácticamente inútil: desplazarse hacia arriba algunas líneas debería revelar la declaración y, por lo tanto, escribir.Si sus variables globales o su bloque de código abarcan mucho más de una pantalla, tendrá graves problemas de diseño y reutilización.Por lo tanto, una de las críticas es que la notación húngara permite a los desarrolladores tener un mal diseño y salirse con la suya fácilmente.Esta es probablemente una de las razones del odio.

Por otro lado, puede haber casos en los que incluso los lenguajes de verificación de tipos en tiempo de compilación se beneficiarían de la notación húngara. vacío punteros o MANEJAREstá en la API win32.Esto confunde el tipo de datos real, y podría ser beneficioso utilizar la notación húngara allí.Sin embargo, si se puede conocer el tipo de datos en el momento de la compilación, ¿por qué no utilizar el tipo de datos apropiado?

En general, no existen razones de peso para no utilizar la notación húngara.Es una cuestión de gustos, políticas y estilo de codificación.

Answer 13

Como programador de Python, la notación húngara se desmorona bastante rápido.En Python, no me importa si algo es una cuerda - me importa si puede actuar como una cadena (es decirsi tiene un ___str___() método que devuelve una cadena).

Por ejemplo, digamos que tenemos foo como un número entero, 12

foo = 12

La notación húngara nos dice que debemos llamarlo iFoo o algo así, para indicar que es un número entero, para que más adelante sepamos qué es.Excepto en Python, eso no funciona, o mejor dicho, no tiene sentido.En Python, decido qué tipo quiero cuando lo uso.¿Quiero una cuerda?bueno si hago algo como esto:

print "The current value of foo is %s" % foo

Nota la %s - cadena.Foo no es una cuerda, sino el % el operador llamará foo.___str___() y utilizar el resultado (suponiendo que exista). foo Sigue siendo un número entero, pero lo tratamos como una cadena si queremos una cadena.Si queremos un flotador, lo tratamos como un flotador.En lenguajes escritos dinámicamente como Python, la notación húngara no tiene sentido, porque no importa de qué tipo sea algo hasta que lo uses, y si necesitas un tipo específico, solo asegúrate de convertirlo a ese tipo (por ejemplo, float(foo)) cuando lo utilices.

Tenga en cuenta que los lenguajes dinámicos como PHP no tienen este beneficio: PHP intenta hacer "lo correcto" en segundo plano basándose en un oscuro conjunto de reglas que casi nadie ha memorizado, lo que a menudo resulta en desastres catastróficos inesperados.En este caso, algún tipo de mecanismo de nomenclatura, como $files_count o $file_name, puede resultar útil.

En mi opinión, la notación húngara es como sanguijuelas.Tal vez en el pasado fueron útiles, o al menos parecían útiles, pero hoy en día es solo escribir mucho más para no obtener muchos beneficios.

Answer 14

El IDE debería impartir esa información útil.El húngaro podría haber tenido algún tipo (no mucho, pero sí algún tipo) de sentido cuando los IDE eran mucho menos avanzados.

Answer 15

Las aplicaciones húngaras son griegas para mí, en el buen sentido

Como ingeniero, no programador, inmediatamente leí el artículo de Joel sobre los méritos de las aplicaciones húngaras: "Hacer que el código incorrecto parezca incorrecto".Me gustan las aplicaciones húngaras porque Imita cómo la ingeniería, las ciencias y las matemáticas representan ecuaciones y fórmulas utilizando símbolos con subíndices y superíndices. (como letras griegas, operadores matemáticos, etc.).Tomemos un ejemplo particular de Ley de gravedad universal de Newton:primero en notación matemática estándar y luego en pseudocódigo húngaro de Apps:

frcGravityEarthMars = G * massEarth * massMars / norm(posEarth - posMars)

En la notación matemática, los símbolos más destacados son los que representan el amable de información almacenada en la variable:fuerza, masa, vector de posición, etc.Los subíndices juegan un papel secundario para aclarar:posición de qué?Esto es exactamente lo que está haciendo Apps Húngaro;te esta diciendo el amable de lo almacenado en la variable primero y luego entrar en detalles: sobre el código más cercano que puede llegar a la notación matemática.

Claramente, una escritura fuerte puede resolver el conflicto entre seguridad y seguridad.ejemplo de cadena insegura del ensayo de Joel, pero no definiría tipos separados para los vectores de posición y velocidad;Ambos son arreglos dobles de tamaño tres y cualquier cosa que le hagas a uno podría aplicarse al otro.Además, tiene mucho sentido concatenar la posición y la velocidad (para crear un vector de estado) o tomar su producto escalar, pero probablemente no agregarlas.¿Cómo permitiría la escritura las dos primeras y prohibiría la segunda, y cómo se extendería dicho sistema a todas las operaciones posibles que desee proteger?A menos que estuviera dispuesto a codificar todas las matemáticas y la física en su sistema de mecanografía.

Además de todo eso, mucha ingeniería se realiza en lenguajes de alto nivel débilmente tipados como Matlab, o antiguos como Fortran 77 o Ada.

Entonces, si tienes un lenguaje sofisticado y el IDE y las aplicaciones húngaras no te ayudan, entonces olvídalo; aparentemente mucha gente lo ha hecho.Pero para mí, peor que un programador novato que trabaja en lenguajes de tipo débil o dinámico, puedo escribir código mejor y más rápido con aplicaciones húngaras que sin ellas.

Answer 16

Es increíblemente redundante e inútil en la mayoría de los IDE modernos, donde hacen un buen trabajo al hacer que el tipo sea evidente.

Además, para mí, es molesto ver intI, strUserName, etc.:)

Answer 17

Si siento que se está impartiendo información útil, ¿por qué no debería ponerla allí donde esté disponible?

Entonces, ¿a quién le importa lo que piensen los demás?Si lo encuentra útil, utilice la notación.

Answer 18

Según mi experiencia, es mala porque:

1 - luego rompes todo el código si necesitas cambiar el tipo de una variable (es decir,si necesita extender un entero de 32 bits a un entero de 64 bits);

2: esta es información inútil ya que el tipo ya está en la declaración o utiliza un lenguaje dinámico donde el tipo real no debería ser tan importante en primer lugar.

Además, con un lenguaje que acepta programación genérica (es decir,funciones donde el tipo de algunas variables no se determina cuando se escribe la función) o con un sistema de escritura dinámica (es decir,cuando el tipo ni siquiera se determina en el momento de la compilación), ¿cómo nombraría sus variables?Y la mayoría de los lenguajes modernos admiten uno u otro, aunque sea de forma restringida.

Answer 19

En Joel Spolsky hace que el código incorrecto parezca incorrecto Explica que lo que todo el mundo considera notación húngara (que él llama sistemas húngaros) no es lo que realmente pretendía ser (lo que él llama aplicaciones húngaras).Desplácese hacia abajo hasta el Yo soy húngaro Dirígete a ver esta discusión.

Básicamente, los sistemas húngaros no valen nada.Simplemente le dice lo mismo que le dirá su compilador y/o IDE.

Apps Húngaro te dice lo que se supone que significa la variable y, de hecho, puede ser útil.

Answer 20

Siempre he pensado que uno o dos prefijos en el lugar correcto no vendrían mal.Creo que si puedo impartir algo útil, como "Oye, esta es una interfaz, no cuentes con un comportamiento específico" allí mismo, como en IEnumerable, debería hacerlo.Los comentarios pueden desordenar mucho más que un simple símbolo de uno o dos caracteres.

Answer 21

Es una convención útil para nombrar controles en un formulario (btnOK, txtLastName, etc.), si la lista de controles aparece en una lista desplegable alfabética en su IDE.

Answer 22

Tiendo a utilizar la notación húngara con controles de servidor ASP.NET solo, de lo contrario, me resulta muy difícil determinar qué controles hay en el formulario.

Tome este fragmento de código:

<asp:Label ID="lblFirstName" runat="server" Text="First Name" />
<asp:TextBox ID="txtFirstName" runat="server" />
<asp:RequiredFieldValidator ID="rfvFirstName" runat="server" ... />

Si alguien puede mostrar una mejor manera de tener ese conjunto de nombres de control sin húngaro, estaría tentado a hacerlo.

Answer 23

El artículo de Joel es genial, pero parece omitir un punto importante:

El húngaro hace una 'idea' particular (nombre + nombre del identificador) único, o casi unique, a través de la base de código, incluso una base de código muy grande.

Eso es enorme para el mantenimiento del código.Significa que puede usar una buena búsqueda de texto de una sola línea (GREP, Findstr, 'Buscar en todos los archivos') para encontrar cada mención de esa 'idea'.

¿Por qué es tan importante cuando tenemos IDE que saben leer código?Porque todavía no son muy buenos en eso.Esto es difícil de ver en una pequeña base de código, pero obvia en una grande, cuando la 'idea' podría mencionarse en comentarios, archivos XML, scripts de perl y también en lugares de control de fuentes externos (documentos, wikis, bases de datos de errores).

También aquí hay que tener un poco de cuidado, p.e.El pastor de token en macros C/C ++ puede ocultar las menciones del identificador.Tales casos pueden tratarse con las convenciones de codificación, y de todos modos tienden a afectar solo una minoría de los identificadores en la base de código.

PDAl punto sobre el uso del sistema de tipos vs.Húngaro: es mejor utilizar ambos.Sólo necesita que el código incorrecto se vea mal si el compilador no lo detecta.Hay muchos casos en los que no es posible hacer que el compilador lo detecte.Pero cuando sea factible, sí, ¡hazlo en su lugar!

Sin embargo, al considerar la viabilidad, considere los efectos negativos de dividir los tipos.p.ej.en C#, envolver 'int' con un tipo no integrado tiene enormes consecuencias.Por tanto, tiene sentido en algunas situaciones, pero no en todas.

Answer 24

Desmentir los beneficios de la notación húngara

• Proporciona una forma de distinguir variables.

Si el tipo es todo lo que distingue un valor de otro, entonces solo puede ser para la conversión de un tipo a otro.Si tiene el mismo valor que se está convirtiendo entre tipos, es probable que deba hacerlo en una función dedicada a la conversión. (He visto restos de VB6 húngaros que usan cadenas en todos los parámetros de sus métodos simplemente porque no podían descubrir cómo deserializar un objeto JSON, o comprender adecuadamente cómo declarar o usar tipos que aceptan valores NULL.) Si tiene dos variables que se distinguen únicamente por el prefijo húngaro y no son una conversión de una a la otra, entonces debe explicar su intención con ellas.

• Hace que el código sea más legible.

He descubierto que la notación húngara vuelve perezosa a la gente con los nombres de las variables.Tienen algo por lo que distinguirlo y no sienten la necesidad de explicar su propósito.Esto es lo que normalmente encontrarás en el código anotado húngaro vs.moderno:SQL vs.grupoSelectSql (o, por lo general, ningún sSQL porque se supone que están usando el ORM instalado por desarrolladores anteriores.), sValor vs.formularioColecciónValor (o, por lo general, tampoco hay sValue, porque resulta que están en MVC y deberían usar sus características de enlace de modelo.), sTipo vs.publicarFuente, etc.

No puede ser legibilidad.Veo más sTemp1, sTemp2...sTempN de cualquier sobrante de VB6 húngaro que todos los demás combinados.

• Previene errores.

Esto sería en virtud del número 2, que es falso.

Answer 25

En palabras del maestro:

http://www.joelonsoftware.com/articles/Wrong.html

Una lectura interesante, como siempre.

Extractos:

"Alguien, en algún lugar, leyó el artículo de Simonyi, donde usaba la palabra “tipo”, y pensó que se refería a tipo, como clase, como en un sistema de tipos, como la verificación de tipos que realiza el compilador.No lo hizo.Explicó con mucho cuidado exactamente lo que quería decir con la palabra "tipo", pero no ayudó.El daño ya estaba hecho".

"Pero todavía hay un enorme valor en Apps Hungría, ya que aumenta la colocación en el código, lo que hace que el código sea más fácil de leer, escribir, depurar y mantener y, lo más importante, hace que el código incorrecto parezca incorrecto".

Asegúrate de tener algo de tiempo antes de leer Joel On Software.:)

Answer 26

Muchas rasones:

• Cualquier IDE moderno le proporcionará el tipo de variable simplemente pasando el mouse sobre la variable.
• La mayoría de los nombres de tipos son muy largos (piense Proveedor de solicitud de cliente Http) para ser utilizado razonablemente como prefijo.
• La información de tipo no lleva la bien información, simplemente está parafraseando la declaración de la variable, en lugar de delinear la objetivo de la variable (pensar miEntero vs. tamaño de página).

Answer 27

No creo que todo el mundo esté rabiosamente en contra.En lenguajes sin tipos estáticos, es bastante útil.Definitivamente lo prefiero cuando se usa para brindar información que aún no está en el tipo.Como en C, char * szNombre dice que la variable se referirá a una cadena terminada en nulo (que no está implícita en char*), por supuesto, un typedef también ayudaría.

Joel publicó un excelente artículo sobre el uso del húngaro para saber si una variable estaba codificada en HTML o no:

http://www.joelonsoftware.com/articles/Wrong.html

De todos modos, no me gusta el húngaro cuando se utiliza para impartir información que ya conozco.

Answer 28

Por supuesto, cuando el 99% de los programadores están de acuerdo en algo, algo anda mal.La razón por la que están de acuerdo aquí es porque la mayoría de ellos nunca han usado correctamente la notación húngara.

Para un argumento detallado, los remito a una publicación de blog que hice sobre el tema.

http://codingthriller.blogspot.com/2007/11/rediscovering-hungarian-notation.html

Answer 29

Comencé a codificar más o menos cuando se inventó la notación húngara y la primera vez que me vi obligado a usarla en un proyecto, la odié.

Después de un tiempo me di cuenta de que cuando se hacía correctamente realmente ayudaba y hoy en día me encanta.

Pero como todo lo bueno, hay que aprenderlo y comprenderlo, y hacerlo correctamente lleva tiempo.

Answer 30

Se abusó de la notación húngara, particularmente por parte de Microsoft, lo que dio lugar a prefijos más largos que el nombre de la variable y muestra que es bastante rígida, particularmente cuando se cambian los tipos (el infame lparam/wparam, de diferente tipo/tamaño en Win16, idéntico en Win32). ).

Por lo tanto, tanto debido a este abuso como a su uso por parte de M$, fue catalogado como inútil.

En mi trabajo, codificamos en Java, pero el fundador proviene del mundo MFC, así que use un estilo de código similar (llaves alineadas, ¡me gusta esto!, mayúsculas para los nombres de los métodos, estoy acostumbrado a eso, prefijos como m_ para los miembros de la clase (campos ), s_ a miembros estáticos, etc.).

Y dijeron que todas las variables deberían tener un prefijo que muestre su tipo (por ejemplo.un BufferedReader se denomina brData).Lo cual se muestra como una mala idea, ya que los tipos pueden cambiar pero los nombres no siguen, o los codificadores no son consistentes en el uso de estos prefijos (¡incluso veo aBuffer, theProxy, etc.!).

Personalmente, elegí algunos prefijos que encuentro útiles, siendo el más importante b para prefijar variables booleanas, ya que son los únicos en los que permito sintaxis como if (bVar) (no se utiliza la transmisión automática de algunos valores a verdadero o falso).Cuando codifiqué en C, utilicé un prefijo para las variables asignadas con malloc, como recordatorio de que debería liberarse más tarde.Etc.

Entonces, básicamente, no rechazo esta notación en su totalidad, sino que tomo lo que parece adecuado para mis necesidades.
Y, por supuesto, cuando contribuyo a algún proyecto (trabajo, código abierto), ¡simplemente uso las convenciones vigentes!