Pregunta

¿Vale la pena aprender la convención o es una pesadilla para la legibilidad y el mantenimiento?

¿Fue útil?

Solución

Teniendo en cuenta que la mayoría de las personas que utilizan Notación húngara está siguiendo la versión mal entendida, yo diría que es bastante inútil.

Si desea utilizar la definición original, podría tener más sentido, pero aparte de eso, es principalmente azúcar sintáctico.

Si lees el Artículo de Wikipedia sobre el tema, encontrarás dos notaciones contradictorias, Sistemas de notación húngara y Aplicaciones Notación húngara.

La definición original y buena es la Aplicaciones Notación húngara, pero la mayoría de la gente usa el Sistemas de notación húngara.

Como ejemplo de los dos, considere anteponer variables con l para longitud, a para área y v para volumen.

Con tal notación, la siguiente expresión tiene sentido:

int vBox = aBottom * lVerticalSide;

pero esto no:

int aBottom = lSide1;

Si está mezclando los prefijos, deben considerarse parte de la ecuación, y volumen = área * longitud está bien para un cuadro, pero copiar un valor de longitud en una variable de área debería generar algunas señales de alerta.

Desafortunadamente, la otra notación es menos útil, donde las personas anteponen los nombres de las variables con el tipo de valor, así:

int iLength;
int iVolume;
int iArea;

algunas personas usan n para número, o i para número entero, f para flotante, s para cadena, etc.

El prefijo original estaba destinado a detectar problemas en ecuaciones, pero de alguna manera ha hecho que el código sea un poco más fácil de leer, ya que no es necesario buscar la declaración de la variable.Con los editores inteligentes actuales en los que simplemente puedes pasar el cursor sobre cualquier variable para encontrar el tipo completo, y no solo una abreviatura, este tipo de notación húngara ha perdido gran parte de su significado.

Pero debes tomar tu propia decisión.Lo único que puedo decir es que no uso ninguno de los dos.


Editar Solo para agregar un breve aviso, mientras no uso Notación húngara, uso un prefijo y es el guión bajo.Le prefijo un _ a todos los campos privados de las clases y, de lo contrario, deletreo sus nombres como lo haría con una propiedad, título con la primera letra en mayúscula.

Otros consejos

La convención de nomenclatura húngara puede resultar útil cuando se utiliza correctamente; desafortunadamente, la mayoría de las veces tiende a utilizarse incorrectamente.

Lea el artículo de Joel Spolsky Hacer que el código incorrecto parezca incorrecto para una perspectiva y justificación apropiadas.

Esencialmente, notación húngara basada en tipos, donde las variables tienen el prefijo información sobre su tipo (p. ej.ya sea que un objeto sea una cadena, un identificador, un int, etc.) es prácticamente inútil y generalmente solo agrega gastos generales con muy pocos beneficios.Lamentablemente, esta es la notación húngara con la que la mayoría de la gente está familiarizada.Sin embargo, la intención de la notación húngara tal como está prevista es agregar información sobre el "tipo" de datos que contiene la variable.Esto le permite dividir tipos de datos de otros tipos de datos que no deberían mezclarse excepto, posiblemente, a través de algún proceso de conversión.Por ejemplo, coordenadas basadas en píxeles vs.coordenadas en otras unidades, o entradas inseguras del usuario versus datos de fuentes seguras, etc.

Mírelo de esta manera, si se encuentra explorando el código para encontrar información sobre una variable, entonces probablemente necesite ajustar su esquema de nombres para contener esa información, esta es la esencia de la convención húngara.

Tenga en cuenta que una alternativa a la notación húngara es utilizar más clases para mostrar la intención del uso de variables en lugar de depender de tipos primitivos en todas partes.Por ejemplo, en lugar de tener prefijos variables para entradas de usuarios no seguras, puede tener una clase contenedora de cadena simple para entradas de usuarios no seguras y una clase contenedora separada para datos seguros.Esto tiene la ventaja, en lenguajes fuertemente tipados, de que el compilador aplique la partición (incluso en lenguajes menos fuertemente tipados, generalmente puede agregar su propio código trampa), pero agrega una cantidad no insignificante de sobrecarga.

Todavía uso la notación húngara cuando se trata de elementos de la interfaz de usuario, donde varios elementos de la interfaz de usuario están relacionados con un objeto/valor en particular, por ejemplo,

lblFirstName para el objeto de etiqueta, txtFirstName para el cuadro de texto.Definitivamente no puedo nombrarlos a ambos "Nombre" incluso si eso es la preocupación/responsabilidad de ambos objetos.

¿Cómo abordan otros el nombramiento de elementos de la interfaz de usuario?

No tiene sentido (y distrae), pero se usa relativamente mucho en mi empresa, al menos para tipos como ints, strings, booleans y doubles.

Cosas como sValue, iCount, dAmount o fAmount, y bFlag están en todas partes.

Érase una vez una buena razón para esta convención.Ahora es un cáncer.

Creo que la notación húngara es una nota a pie de página interesante en el 'camino' hacia un código más legible y, si se hace correctamente, es preferible a no hacerlo.

Sin embargo, al decir eso, prefiero eliminarlo y en lugar de esto:

int vBox = aBottom * lVerticalSide;

escribe esto:

int boxVolume = bottomArea * verticalHeight;

Es 2008.¡Ya no tenemos pantallas de ancho fijo de 80 caracteres!

Además, si está escribiendo nombres de variables que son mucho más largos, debería considerar refactorizarlos en objetos o funciones de todos modos.

Perdón por seguir con una pregunta, pero ¿el prefijo de interfaces con "I" califica como notación húngara?Si ese es el caso, entonces sí, mucha gente lo está usando en el mundo real.Si no, ignora esto.

Veo la notación húngara como una forma de eludir la capacidad de nuestra memoria a corto plazo.Según los psicólogos, podemos almacenar aproximadamente 7 más o menos 2 trozos de información.La información adicional que se agrega al incluir un prefijo nos ayuda al proporcionar más detalles sobre el significado de un identificador incluso sin otro contexto.En otras palabras, podemos adivinar para qué sirve una variable sin ver cómo se usa o declara.Esto se puede evitar aplicando técnicas como encapsulación y el principio de responsabilidad única.

No sé si esto se ha estudiado empíricamente o no.Mi hipótesis es que la cantidad de esfuerzo aumenta dramáticamente cuando intentamos comprender clases con más de nueve variables de instancia o métodos con más de 9 variables locales.

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

  • l para locales
  • un argumento
  • m para miembro
  • g para 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í.

Cuando veo debates en húngaro, me alegra ver a la gente pensando mucho en cómo hacer que su código sea más claro y cómo hacer que los errores sean más visibles.¡Eso es exactamente lo que todos deberíamos estar haciendo!

Pero no olvides que tienes algunas herramientas poderosas a tu disposición además de nombrar.

Método de extracción Si sus métodos se están volviendo tan largos que sus declaraciones de variables se han desplazado fuera de la parte superior de la pantalla, considere hacer sus métodos más pequeños.(Si tiene demasiados métodos, considere una nueva clase).

Escritura fuerte Si descubre que está tomando código postals almacenados en una variable entera y asignándolos a un tamaño del zapato variable entera, considere crear una clase para códigos postales y una clase para talla de zapato.Entonces su error será detectado en el momento de la compilación, en lugar de requerir una inspección cuidadosa por parte de un humano.Cuando hago esto, generalmente encuentro un montón de lógica específica de código postal y talla de zapato que he esparcido alrededor de mi código, que luego puedo trasladar a mis nuevas clases.De repente, todo mi código se vuelve más claro, más simple y está protegido contra ciertas clases de errores.Guau.

Para resumir:Sí, piense detenidamente en cómo utilizar los nombres en el código para expresar sus ideas con claridad, pero también busque otras potentes herramientas de OO a las que pueda recurrir.

No uso un sentido muy estricto de la notación húngara, pero me encuentro usándolo con moderación para algunos objetos personalizados comunes para ayudar a identificarlos, y también tiendo a anteponer objetos de control de interfaz gráfica de usuario con el tipo de control que son.Por ejemplo, labelFirstName, textFirstName y buttonSubmit.

Utilizo nombres húngaros para elementos de la interfaz de usuario como botones, cuadros de texto y etiquetas.El principal beneficio es la agrupación en Visual Studio Intellisense Popup.Si quiero acceder a mis etiquetas, simplemente empiezo a escribir lbl....y Visual Studio sugerirá todas mis etiquetas, agrupadas correctamente.

Sin embargo, después de hacer más y más cosas de Silverlight y WPF, aprovechando el enlace de datos, ya ni siquiera nombro todos mis controles, ya que no tengo que hacer referencia a ellos desde el código subyacente (dado que realmente ya no hay ningún código subyacente). ;)

Lo que está mal es mezclar estándares.

Lo correcto es asegurarse de que todos hagan lo mismo.

int Box = iBottom * nVerticleSide

El prefijo original estaba destinado a usarse para detectar problemas en las ecuaciones, pero de alguna manera se ha convertido en hacer que el código sea un poco más fácil de leer, ya que no tiene que buscar la declaración variable.Con los editores inteligentes de hoy donde simplemente puede pasar la variable para encontrar el tipo completo, y no solo una abreviatura para ello, este tipo de notación húngara ha perdido mucho su significado.

Estoy rompiendo un poco el hábito, pero anteponer el tipo puede ser útil en JavaScript que no tiene una escritura variable fuerte.

Cuando uso un lenguaje escrito dinámicamente, ocasionalmente uso Apps húngaro.Para lenguajes escritos estáticamente no lo hago.ver mi explicacion en el otro hilo.

La notación húngara no tiene sentido en idiomas con seguridad tipográfica.p.ej.Un prefijo común que verá en el código antiguo de Microsoft es "lpsz", que significa "puntero largo a una cadena terminada en cero".Desde principios de 1700 no hemos utilizado arquitecturas segmentadas donde existan punteros cortos y largos, la representación de cadena normal en C++ siempre termina en cero y el compilador tiene seguridad de tipos, por lo que no nos permite aplicar operaciones que no sean de cadena al cadena.Por lo tanto, ninguna parte de esta información es de utilidad real para un programador: solo se trata de escribir más.

Sin embargo, uso una idea similar:prefijos que aclaran la uso de una variable.Los principales son:

  • metro = miembro
  • c = constante
  • s = estático
  • v = volátil
  • p = puntero (y pp = puntero a puntero, etc.)
  • i = índice o iterador

Estos se pueden combinar, por lo que una variable miembro estática que sea un puntero sería "mspName".

¿Dónde son útiles?

  • Cuando el uso es importante, es una buena idea recordarle constantemente al programador que una variable es (por ejemplo) un volátil o un puntero.
  • La desreferenciación de punteros solía molestarme hasta que usé el prefijo p.Ahora es muy fácil saber cuándo tienes un objeto (Naranja), un puntero a un objeto (pOrange) o un puntero a un puntero a un objeto (ppOrange).Para eliminar la referencia a un objeto, simplemente coloque un asterisco delante de él para cada p en su nombre.Caso resuelto, ¡no más errores deref!
  • En los constructores normalmente encuentro que el nombre de un parámetro es idéntico al nombre de una variable miembro (por ejemplo,tamaño).Prefiero usar "msize = size"; que "size = thesize" o "this.size = size".También es mucho más seguro:No uso accidentalmente "size = 1" (configurando el parámetro) cuando quería decir "mSize = 1" (configurando el miembro)
  • En los bucles, todas mis variables iteradoras son nombres significativos.La mayoría de los programadores usan "i" o "index" y luego tienen que inventar nuevos nombres sin sentido ("j", "index2") cuando quieren un bucle interno.Utilizo un nombre significativo con un prefijo i (iHospital, iWard, iPatient) para saber siempre qué está iterando un iterador.
  • En los bucles, puedes mezclar varias variables relacionadas usando el mismo nombre base con diferentes prefijos:Naranja naranja = pOrange[iOrange];Esto también significa que no comete errores de indexación de matrices (pApple[i] se ve bien, pero escríbalo como pApple[iOrange] y el error será inmediatamente obvio).
  • Muchos programadores usarán mi sistema sin saberlo:agregando un sufijo largo como "Índice" o "Ptr"; en mi humilde opinión, no hay ninguna buena razón para usar una forma más larga que un solo carácter, así que uso "i" y "p".Menos escritura, más consistente, más fácil de leer.

Este es un sistema simple que agrega información significativa y útil al código y elimina la posibilidad de cometer muchos errores de programación simples pero comunes.

He estado trabajando para IBM durante los últimos 6 meses y no lo he visto por ningún lado (gracias a Dios porque lo odio). Veo camelCase o c_style.

thisMethodIsPrettyCool()
this_method_is_pretty_cool()

Depende de su idioma y entorno.Como regla general, no lo usaría, a menos que el entorno de desarrollo en el que se encuentre dificulte encontrar el tipo de variable.

También hay dos tipos diferentes de notación húngara.Vea el artículo de Joel.No puedo encontrarlo (sus nombres no hacen que sea fácil de encontrar), ¿alguien tiene un enlace al que me refiero?

Editar:Wedge tiene el artículo al que me refiero en su publicación.

Forma original (La notación húngara correcta :)) donde prefijo significa tipo (es decir,longitud, cantidad) del valor almacenado por variable está bien, pero no es necesario en todo tipo de aplicaciones.

La forma popular (La notación húngara equivocada) donde prefijo significa tipo (String, int) es inútil en la mayoría de los lenguajes de programación modernos.

Especialmente con nombres sin sentido como strA.No puedo entender que la gente use nombres sin sentido con prefijos largos que no aportan nada.

Utilizo tipos basados ​​(Systems HN) para componentes (por ejemplo, editFirstName, lblStatus, etc.) ya que hace que la función de autocompletar funcione mejor.

A veces uso la aplicación HN para variables donde la información de tipo es suficiente.Es decir, fpX indica una variable de punta fija (tipo int, pero no se puede mezclar ni combinar con un int), rawInput para cadenas de usuario que no han sido validadas, etc.

Siendo un programador PHP donde está escrito de manera muy flexible, no me propongo usarlo.Sin embargo, ocasionalmente identificaré algo como una matriz o un objeto según el tamaño del sistema y el alcance de la variable.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top