Buenos ejemplos de notación húngara?

Esta pregunta es buscar buenos ejemplos de notación húngara, para que podamos reunir una colección de estos.

Edit: I agree that Hungarian for types isn't that necessary, I'm hoping for more specific examples where it increases readability and maintainability, like Joel gives in his article (as per my answer).

16
Esta pregunta se creó cuando se inició el desbordamiento de la pila y realmente no es el tipo de pregunta permitida hoy para este sitio. Todavía es un recurso útil y debe conservarse por razones históricas y por los atractivos que aporta al sitio.
agregado el autor Lance Roberts, fuente

21 Respuestas

El problema de pedir buenos ejemplos de notación húngara es que todos tengan su propia idea de cómo es un buen ejemplo. Mi opinión personal es que el mejor notación húngara es no húngaro Notación . La notación fue originalmente destinada a denotar el uso previsto de una variable en lugar de su tipo, pero generalmente se usa para información de tipo, particularmente para controles de formulario (por ejemplo, txtFirstName para un texto cuadro para el primer nombre de alguien). Esto hace que el código sea menos sostenible, en términos de legibilidad (por ejemplo, "prepIn nounTerms prepOf nounReadability") y refactorización para cuando el tipo necesita ser cambiado (hay "lParams" en la API de Win32 que han cambiado el tipo).

Probablemente deberías considerar no usarlo en absoluto. Ejemplos:

  • strFirstName - this can just be firstName since it's obvious what it's for, the type isn't that important and should be obvious in this case. If not obvious, the IDE can help you with that.
  • txtFirstName - this can change to FirstNameTextBox or FirstName_TextBox. It reads better and you know it's a control and not just the text.
  • CAccount - C was used for class names in MFC but you really don't need it. Account is good enough. The uppercase name is the standard convention for types (and they only appear in specific places so they won't get confused with properties or methods)
  • ixArray (index to array) - ix is a bit obscure. Try arrayIndex.
  • usState (unsafe string for State) - looks like "U.S. State". Better go with state_UnsafeString or something. Maybe even wrap it in an UnsafeString class to at least make it type-safe.
37
agregado
Estoy de acuerdo en que debemos usarlo para el uso intencionado, y eso es lo que espero que la gente contribuya, en cuanto a mi próxima aplicación, me gustaría crear un estándar desde el primer momento.
agregado el autor Lance Roberts, fuente
Gracias por todos los ejemplos concretos.
agregado el autor Lance Roberts, fuente
Si la notación húngara se usa de forma consistente con su intención original de mostrar intento , entonces bien. Pero una consistencia TOTAL es un duende de las mentes de los jóvenes programadores.
agregado el autor Mark Cidade, fuente
En PHP, no todos los tipos son obvios solo por el nombre de la variable. ¿Qué tal un código de clasificación bancaria $ BankSortCode ? ¿Es "int", o una "cadena" porque tiene guiones? La altura de un usuario $ UserHeight ? Podría ser "int" si está en mm, pero ¿qué pasa si está en pies/pulgadas y es una "cadena" para acomodar las palabras pies/pulgadas , o "', o el punto? Uso el subrayado con camelCase - $ int_BankSortCode , $ str_UserName , $ ary_teamNames . Su respuesta no es realmente válida para
agregado el autor James, fuente
Vale la pena mencionar las Convenciones de nomenclatura general en MSDN ( msdn.microsoft.com/en -us/library/ms229045.aspx ). Dicen "No usar notación húngara".
agregado el autor Fernando, fuente
Puede hacer todo tipo de argumentos que hagan que ciertos beneficios de las prácticas de codificación parezcan superfluos. Vamos a tomar CamelCase ... ¿Por qué tenemos que minúsculas al principio de la variable? ¿Por qué mayúsculas las siguientes palabras? userName = UserName = username, son tan fáciles de leer y entender. La consistencia es clave cuando se utilizan convenciones de codificación, eso es lo más importante, y sugerir que la notación húngara es de alguna manera peor, es simplemente ignorar que todas las convenciones de codificación son válidas y útiles, si se siguen de manera cohe
agregado el autor Mike, fuente
@ gutofb7: tu enlace es para .NET. Esta no es una pregunta específica de .NET. Todos debemos entender por qué se ha realizado esta recomendación (piense en "Ventana de definición de código") antes de tratar de aplicar este argumento para todos los entornos e idiomas. Hay lugares donde AppHungarian correctamente utilizado es una bendición, y todos los otros métodos mencionados aquí (jerarquías de clase, usando nombres extra largos, información de tipo de codificación) son inferiores.
agregado el autor Rom, fuente
El último punto presentado aquí es lo primero que me vino a la mente después de leer el artículo original de Joel. Este es uno de los propósitos de las jerarquías de clase, y el uso de convenciones de nomenclatura para hacerlo no es óptimo.
agregado el autor Nerdfest, fuente

El artículo ahora clásico, como se menciona en otros posts húngaros, es el del sitio de Joel:

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

27
agregado

pag

(for pagointer). Its pagretty much the only pagrefix I use. I think it adds a lot to a variable (eg that its a pagointer) and so should be treated a little more respagectfully. Hungarian for datatypages is somewhat pagasse now IDEs can tell you what the typage is (in only a few seconds hovering over the variable name), so its not so impagortant. But treating a pagointer as if its data is not good, so you want to make sure it's obvious to the user what it is even if he makes assumpagtions he shouldn't when coding.
16
agregado
Estoy de acuerdo, aunque me parece mucho mejor poner _p al final. Hace que las referencias de estructuras de los punteros sean mucho más fáciles de leer, p. some_struct_p-> some_member (y some_struct_p.some_member se destacarían como obviamente incorrectos (en el significado del artículo de Joel)).
agregado el autor hlovdal, fuente
También tuve una pregunta similar, y llegué a conclusiones algo similares. Recopilación aquí [otoño 2014].
agregado el autor Nick Alexeev, fuente
Sí, esta es la única vez que consideraría usar la notación húngara también.
agregado el autor cheduardo, fuente

t

Datos corruptos. Prefija todos los datos entrantes de una fuente no confiable para hacer que esa variable esté contaminada. Toda la información contaminada debe ser limpiada antes de que se realice un trabajo real en ella.

15
agregado

No use prefijos específicos del idioma.

Usamos:

n: Number 
p: Percentage 1=100% (for interest rates etc)
c: Currency
s: String
d: date
e: enumeration
o: object (Customer oCustomer=new Customer();)
...

Usamos el mismo sistema para todos los idiomas:

SQL
C
C#
Javascript
VB6
VB.net
...

Es un salvavidas.

6
agregado
p como un prefijo en los lenguajes que admiten punteros, pero que no significa puntero ... ¡aterrador!
agregado el autor Greg Beech, fuente
Ya no usamos punteros (si es que hay alguno). En nuestra línea de trabajo, use muchas tasas de interés (porcentaje) y sin punteros. La idea es usar prefijos de lenguaje cruzado. No son los prefijos específicos los que cuentan. Elige el tuyo.
agregado el autor pkario, fuente
Yo uso enSomething para la variable que contiene la enumeración.
agregado el autor pkario, fuente
Yo uso enSomething no solo eSomething
agregado el autor Guy Cohen, fuente

Encuentro que la notación húngara a veces puede ser útil en lenguajes dinámicos. Estoy pensando específicamente en Actionscript del lado del servidor (esencialmente solo javascript), pero podría aplicarse en cualquier otro lugar. Dado que no hay información de tipo real, la notación húngara a veces puede ayudar a que las cosas sean más fáciles de entender.

5
agregado

Devil's Advocate: el mejor ejemplo de la notación húngara es no usarlo. :RE

No obtenemos ninguna ventaja con el uso de la notación húngara con los IDE modernos porque conocen el tipo. Agrega trabajo cuando se refactoriza un tipo para una variable ya que el nombre también debería cambiarse (y la mayoría de las veces cuando se trata de una variable, se sabe de qué tipo se trata).

También puede entrar en problemas de orden con la notación. Si usa p para puntero y a para dirección, ¿llama a su variable apStreet o paStreet? La legibilidad disminuye cuando no tienes coherencia, y tienes que usar un espacio mental valioso cuando tienes que recordar el orden en el que tienes que escribir la notación.

5
agregado
La notación húngara no debe usarse para tipos. Estás completamente correcto allí. Sin embargo, la intención original era usarlo para cosas no especificadas por tipos, y hay usos potenciales allí.
agregado el autor David Thornley, fuente
Estoy de acuerdo en que no necesita usarlo para todos los tipos, estoy esperando buenos ejemplos como Joel da, donde se agrega legibilidad y facilidad de uso.
agregado el autor Lance Roberts, fuente

El único húngaro que ya es realmente útil es m_ para las variables miembro. (También uso sm_ para miembros estáticos, porque ese es el "otro" ámbito que todavía existe). Con los monitores de pantalla ancha y los compiladores que toman nombres de variables de ocho mil millones de caracteres, la abreviatura de los nombres de tipo simplemente no lo vale.

4
agregado

Estaba totalmente en contra de la notación húngara hasta que realmente comencé a leer al respecto y tratar de entender su intención original.
Después de leer Joels post "Wrong" y el artículo "Redescubrir la notación húngara", realmente cambié de idea. Hecho correcto, creo que debe ser extremadamente poderoso.

Wrong by Joel Spolsky
http://www.joelonsoftware.com/articles/Wrong.html

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

Creo que la mayoría de los Naysayers nunca lo han intentado de verdad y realmente no lo entienden. Me encantaría probarlo en un proyecto real.

4
agregado

La notación húngara (carcasa de camello, tal como lo aprendí) es invaluable cuando heredas un proyecto de software.

Sí, puedes 'desplazarte' sobre una variable con tu IDE y descubrir qué clase es, pero si estás navegando por varios miles de líneas de código, no querrás tener que detener esos pocos segundos, cada ... .. soltero .... tiempo ....

Recuerde: no está escribiendo código solo para usted o su equipo. También lo está escribiendo para la persona que debe recoger este código dentro de 2 a 5 años y mejorarlo.

4
agregado
La carcasa de camello y la notación húngara son cosas diferentes. Camel Casing solo está haciendo ThisHithYourNames (cada palabra comienza con una letra mayúscula). La notación húngara implica anteponer algún tipo de ID al nombre.
agregado el autor Herms, fuente
solo es útil si incluye una leyenda para los prefijos; de lo contrario, podrían ser demasiado crípticos para un lector futuro.
agregado el autor Mark Cidade, fuente
Interesante. Originalmente estaba bajo el supuesto de que eran iguales porque siempre usamos los mismos prefijos (str, int, dbl, obj, dat, etc.) y eso estaba en dos lugares diferentes.
agregado el autor David, fuente

Creo que la clave para sacar del artículo de Joel, vinculado anteriormente, y la notación húngara en general, es usarlo cuando hay algo no obvio sobre la variable.

Un ejemplo, del artículo, está codificado frente a cadenas no codificadas, no es que debas usar "us" húngaro para cadenas inseguras y "s" para cadenas seguras, es que debes tener algún identificador para indica que una cadena es segura o no. Si se convierte en estándar, es fácil ver cuándo se está rompiendo el estándar.

3
agregado

Encuentro que el único punto útil es cuando se declaran controles de interfaz, txtUsername, txtPassword, ddlBirthMonth. No es perfecto, pero ayuda en formas/proyectos grandes.

No lo uso para variables u otros elementos, solo controles.

2
agregado

The name of the variable should describe what it is. Good variable naming makes Hungarian notation useless.

However, sometimes you'd use Hungarian notation in addition to good variable naming. m_numObjects has two "prefixes:" m_ and num. m_ indicates the scope: it's a data member tied to this. num indicates what the value is.

No me siento obstaculizado en absoluto cuando leo el código "bueno", incluso si contiene algo de "húngaro". Derecha: leo el código, no hago clic en él. (De hecho, apenas uso mi mouse alguna vez cuando estoy codificando, o cualquier función de búsqueda específica de programación vudú).

I am slowed when I read things like m_ubScale (yes, I'm looking at you, Liran!), as I have to look at its usage (no comments!) to find out what it scales (if at all?) and it's datatype (which happens to be a fixed-point char). A better name would be m_scaleFactor or m_zoomFactor, with a comment as a fixed-point number, or even a typedef. (In fact, a typedef would be useful, as there are several other members of several classes which use the same fixed-point format. However, some don't, but are still labeled m_ubWhatever! Confusing, to say the least.)

Creo que el húngaro estaba destinado a ser un complemento del nombre de la variable, no un reemplazo de la información. Además, muchas veces la notación húngara no agrega nada a la legibilidad de la variable, desperdiciando bytes y leyendo el tiempo.

Solo mi 2 ¢.

2
agregado

Además de usar 'p' para puntero, me gusta la idea de usar 'cb' y 'cch' para indicar si un parámetro de tamaño de búfer (o variable) es un recuento de bytes o un recuento de caracteres (también he visto ... raramente - 'ce' usado para indicar un recuento de elementos). Entonces, en lugar de transmitir tipo, el prefijo transmite el uso o la intención.

Lo admito, no uso el prefijo tan consistentemente como debería, pero me gusta la idea.

2
agregado

Estoy de acuerdo en que la notación húngara ya no es particularmente útil. Pensé que su intención original era indicar no el tipo de datos, sino el tipo de entidad. En una sección de código que incluye los nombres de los clientes, los empleados y el usuario, por ejemplo, puede nombrar las variables de cadena locales cusName, empName y usrName. Eso ayudaría a distinguir entre nombres de variables que suenan similares. Los mismos prefijos para las entidades se usarán en toda la aplicación. Sin embargo, cuando se utiliza OO, y se trata de objetos, esos prefijos son redundantes en Customer.Name, Employee.Name y User.Name.

2
agregado
Excelente punto allí.
agregado el autor strager, fuente
no solo el tipo de datos también el alcance .... :)
agregado el autor Guy Cohen, fuente

Una pregunta muy antigua, pero aquí hay un par de prefijos "húngaros" que uso regularmente:

mi

     

para variables locales, para distinguir la localidad donde el nombre podría tener sentido en un contexto global. Si ve myFoo, solo se usa en esta función, independientemente de cualquier otra cosa que hagamos con Foos en cualquier otro lado.

myStart = GetTime();
doComplicatedOperations();
print (GetTime() - myStart);

y

tmp

     

para copias temporales de valores en bucles o operaciones de varios pasos. Si ve dos variables de tmpFoo más de un par de líneas entre sí, es casi seguro que no están relacionadas.

tmpX = X; 
tmpY = Y;
X = someCalc(tmpX, tmpY);
Y = otherCalc(tmpX, tmpY);

ysometimes old ynew in for similar reasons to tmp, usually in longer loops or functions.

2
agregado

m

Al usar un ORM (como hibernar), tiende a tratar objetos administrados y no administrados. El cambio de un objeto gestionado se reflejará en la base de datos sin llamar a un guardado explícito, mientras que tratar con un objeto gestionado requiere una llamada a guardar explícita. Cómo lidiar con el objeto será diferente dependiendo de cuál sea.

2
agregado

Solo uso p para un puntero, y eso es todo. Y eso es solo si estoy en C ++. En C# no uso ninguna notación húngara. p.ej.

MyClass myClass;
MyClass* pMyClass;

Eso es todo :)

Edit: Oh, I just realised that's a lie. I use "m_" for member variables too. e.g.

class
{
private:
bool m_myVar;
}
1
agregado

Bueno, lo uso solo con variables de control de ventana. Uso btn_, txt_, lbl_ etc. para detectarlos. También me parece útil buscar el nombre del control escribiendo su tipo (btn_, etc.).

1
agregado

Me encuentro usando 'w' que significa 'trabajar', como un prefijo en lugar de 'temp' o 'tmp', para las variables locales que están justo allí para juntar datos, como:

Public Function ArrayFromDJRange(rangename As Range, slots As Integer) As Variant

' this function copies a Disjoint Range of specified size into a Variant Array 7/8/09 ljr

Dim j As Integer
Dim wArray As Variant
Dim rCell As Range

wArray = rangename.Value ' to initialize the working Array
ReDim wArray(0, slots - 1) ' set to size of range
j = 0

For Each rCell In rangename
    wArray(0, j) = rCell.Value
    j = j + 1
Next rCell

ArrayFromDJRange = wArray

End Function
0
agregado

No hay tal cosa como un buen ejemplo de notación húngara. Simplemente no lo use. Ni siquiera si usa un lenguaje débilmente tipado. Vivirás más feliz.

Pero si realmente necesita algún motivo para no usarlo, este es mi favorito, extraído de este excelente enlace :

Un truco de seguimiento en la notación húngara es "cambiar el tipo de una variable pero no cambiar el nombre de la variable". Esto se realiza casi invariablemente en aplicaciones de Windows con la migración de Win16: - WndProc (HWND hW, WORD wMsg, WORD wParam, LONG lParam) a Win32 WndProc (HWND hW, UINT wMsg, WPARAM wParam, LPARAM lParam) donde w valora la pista que son palabras, pero realmente se refieren a longs. El valor real de este enfoque viene claro con la migración de Win64, cuando los parámetros serán de 64 bits de ancho, pero los antiguos prefijos "w" y "l" se mantendrán para siempre.

0
agregado