¿Buenos ejemplos de notación húngara? [cerrado]

StackOverflow https://stackoverflow.com/questions/202107

Pregunta

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

Editar: Estoy de acuerdo en que el húngaro para los tipos no es tan necesario, espero ejemplos más específicos en los que aumente la legibilidad y la capacidad de mantenimiento, como Joel da en su artículo (según mi respuesta ).

¿Fue útil?

Solución 2

El artículo ahora clásico, como se menciona en otras publicaciones húngaras, es el del sitio de Joel:

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

Otros consejos

El problema de pedir buenos ejemplos de notación húngara es que cada uno tendrá su propia idea de cómo es un buen ejemplo. Mi opinión personal es que la mejor Notación húngara es no húngaro Notación . La notación originalmente estaba 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 casilla para el nombre de alguien. Esto hace que el código sea menos fácil de mantener, en términos de legibilidad (por ejemplo, " prepIn nounTerms prepOf nounReadability ") y refactorización para cuando el tipo debe cambiarse (hay " lParams " en la API de Win32 que han cambiado de tipo).

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

  • strFirstName : puede ser firstName ya que es obvio para qué sirve, el tipo no es tan importante y debería ser obvio en este caso. Si no es obvio, el IDE puede ayudarte con eso.
  • txtFirstName : esto puede cambiar a FirstNameTextBox o FirstName_TextBox . Se lee mejor y sabes que es un control y no solo el texto.
  • CAccount - C se usó para los nombres de clase en MFC pero realmente no lo necesitas. Cuenta es suficiente. El nombre en mayúsculas es la convención estándar para los tipos (y solo aparecen en lugares específicos para que no se confundan con las propiedades o los métodos)
  • ixArray (indexar a array ) - ix es un poco oscuro. Prueba arrayIndex .
  • usState (cadena insegura para Estado ): se ve como " U.S. Estado " ;. Mejor vaya con estado _ UnsafeString o algo así. Tal vez incluso envuélvalo en una clase UnsafeString para al menos hacer que sea seguro para el tipo.

p

(para puntero). Es prácticamente el único prefijo que uso. Creo que agrega mucho a una variable (por ejemplo, es un puntero) y, por lo tanto, debe tratarse con un poco más de respeto.

El húngaro para tipos de datos está algo pasado ahora. Los IDEs pueden decirle cuál es el tipo (en solo unos segundos sobre el nombre de la variable), por lo que no es tan importante. Pero tratar un puntero como si sus datos no fueran buenos, por lo que debe asegurarse de que sea obvio para el usuario qué es lo que es, incluso si hace suposiciones que no debería hacer cuando codifica.

t

Datos contaminados. Prefije todos los datos entrantes de una fuente no confiable para hacer que la variable esté contaminada. Todos los datos contaminados deben limpiarse antes de realizar cualquier trabajo real en ellos.

No tiene sentido usar húngaro para indicar tipos porque el compilador ya lo hace por ti.

Donde el húngaro es útil es distinguir entre tipos de variables lógicamente diferentes que tienen el mismo tipo en bruto. Por ejemplo, si está utilizando ints para representar coordenadas, podría prefijar coordenadas x con coordenadas x, y con y y distancias con d. Así que tendrías un código que parece

dxHighlight = xStart - xEnd

yHighlight = yLocation + 3

yEnd = yStart + dyHeight

dyCode = dyField * 2

y así sucesivamente. Es útil porque puede detectar errores de un vistazo: si agrega un dy a a y, siempre obtiene a y. Si restas dos x siempre obtienes un dx. Si multiplicas un dy por un escalar, siempre obtienes un dy. Y así. Si ves una línea como

yTop = dyText + xButton

sabes de un vistazo que está mal porque agregar un dy y una x no tiene sentido. El compilador no pudo captar esto porque, por lo que se puede decir, está agregando un int a un int que está bien.

No utilice prefijos específicos de idioma.

Utilizamos: 

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.

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

No obtenemos ninguna ventaja al usar 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 tendría que cambiarse (y la mayoría de las veces, cuando se trata de una variable, ya sabes de qué tipo es).

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

A veces, la notación húngara puede ser útil en idiomas dinámicos. Estoy pensando específicamente en Server Side Actionscript (esencialmente solo en javascript), pero podría aplicarse en otros lugares. Como no hay información de tipo real, la notación húngara a veces puede ayudar a que las cosas sean un poco más fáciles de entender.

El único húngaro que es realmente útil ya 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 monitores de pantalla panorámica y compiladores que toman nombres de variables de ocho mil millones de caracteres, los nombres de tipo abreviado simplemente no valen la pena.

La notación húngara (cubierta de camello, como lo aprendí) tiene un valor incalculable cuando se hereda un proyecto de software.

Sí, puede "desplazarse" sobre una variable con su IDE y averiguar qué clase es, pero si está hojeando varios miles de líneas de código, no querrá tener que detenerse durante esos pocos segundos. cada .... solo .... tiempo ....

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

Estaba muy en contra de la notación húngara hasta que empecé a leer sobre eso y traté de entender su intención original.
Después de leer la publicación de Joels " Incorrecto " y el artículo " Redescubriendo la notación húngara " Realmente cambié de opinión. Hecho correctamente, creo que debe ser extremadamente poderoso.

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

Redescubriendo la notación húngara
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.

Creo que la clave para eliminar el artículo de Joel, vinculado arriba, y la Notación Húngara en general, es usarlo cuando hay algo no obvio acerca de la variable.

Un ejemplo, del artículo, está codificado frente a cadenas no codificadas, no es que debas usar húngaro 'us' para cadenas inseguras y 's' para cadenas seguras, es que deberías tener alguna identificador para indicar que una cadena es segura o no. Si se convierte en estándar, es fácil ver cuándo se rompe el estándar.

m

Cuando utiliza un ORM (como hibernación), 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 un objeto administrado requiere una llamada guardada explícita. La forma en que manejes el objeto será diferente según cuál sea.

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

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

Además de usar 'p' para el 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 (he También se ve, rara vez, se utiliza 'ce' para indicar un recuento de elementos). Entonces, en lugar de transmitir el tipo, el prefijo transmite el uso o la intención.

Admito que no uso el prefijo de la manera más consistente posible, pero me gusta la idea.

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 involucra los nombres de clientes, empleados y usuarios, por ejemplo, puede nombrar las variables de cadena locales cusName, empName y usrName. Eso ayudaría a distinguir entre nombres de variables de sonido similar. Los mismos prefijos para las entidades se utilizarían en toda la aplicación. Sin embargo, cuando se usa OO y se trata de objetos, esos prefijos son redundantes en Customer.Name, Employee.Name y User.Name.

El nombre de la variable debe describir lo que es. Un buen nombre de variable hace que la notación húngara sea inútil.

Sin embargo, a veces se usa la notación húngara además de una buena denominación de variables. m_numObjects tiene dos " prefijos: " m_ y num. m_ indica el alcance: es un miembro de datos vinculado a esto . num indica cuál es el valor .

No me siento obstaculizado en absoluto cuando leo " bien " código, incluso si contiene algún " húngaro. " A la derecha: leí el código, no hago clic en él. (De hecho, casi no uso mi mouse cuando codifico, o cualquier función de búsqueda específica para voodoo).

Me detengo cuando leo cosas como m_ubScale ( sí, te estoy mirando, Liran! ), ya que tengo que mirar su uso (¡sin comentarios!) para averiguar qué se escala (si es que lo hace?) y su tipo de datos (que es un personaje de punto fijo). Un nombre mejor sería m_scaleFactor o m_zoomFactor, con un comentario como un número de punto fijo, o incluso un typedef. (De hecho, un typedef sería útil, ya que hay varios otros miembros de varias clases que usan el mismo formato de punto fijo. Sin embargo, algunos no lo hacen, pero aún están etiquetados como m_ubWhatever! Confusing, por decir lo menos.)

Creo que se pensaba que el húngaro era un aditivo al nombre de la variable, no un sustituto de la información. Además, muchas veces la notación húngara no agrega nada a la legibilidad de la variable, el desperdicio de bytes y el tiempo de lectura.

Sólo mi 2 & # 162 ;.

Una pregunta muy antigua, pero aquí hay un par de " Húngaro " prefijos 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 lugar. 

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

y

  

tmp

     

para copias temporales de valores en bucles u operaciones de varios pasos. Si ves dos variables tmpFoo a 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);

y, a veces, antiguo y nuevo por razones similares a tmp , generalmente en bucles o funciones más largos.

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

MyClass myClass;
MyClass* pMyClass;

Eso es todo :)

Editar: Oh, me acabo de dar cuenta de que es una mentira. Yo uso " m_ " para las variables miembro también. por ejemplo 

class
{
private:
bool m_myVar;
}

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

No hay tal cosa como un buen ejemplo de notación húngara. Simplemente no lo uses. Ni siquiera si está utilizando un lenguaje mal escrito. Vivirás más feliz.

Pero si realmente necesitas alguna razón para no usarlo, este es mi favorito, extraído de esto gran 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 hace casi invariablemente en las aplicaciones de Windows con la migración desde Win16: - WndProc (HWND hW, WORD wMsg, WORD wParam, LONG lParam) a Win32 WndProc (HWND hW, UINT wMsg, WPARAM wParam, LPARAM lParam) donde la w valora el valor que son palabras, pero en realidad se refieren a largos. El valor real de este enfoque queda claro con la migración de Win64, cuando los parámetros tendrán un ancho de 64 bits, pero el antiguo " w " y " l " los prefijos permanecerán para siempre.

Me encuentro a mí mismo usando 'w' que significa 'trabajando', como prefijo en lugar de 'temp' o 'tmp', para las variables locales que están ahí para recopilar 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
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top