uppercamelcase notacion hungarian hungara naming-conventions hungarian-notation

naming conventions - notacion - Buenos ejemplos de notación húngara?



notacion hungara pdf (22)

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 tipos no es tan necesario, estoy esperando ejemplos más específicos donde aumente la legibilidad y la facilidad de mantenimiento, como Joel da en su artículo (según mi respuesta).


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 (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.


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 deba usar húngaro ''us'' para cadenas inseguras y ''s'' para cadenas seguras, es que debe tener algún identificador para indicar 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.


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.


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.



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.


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.


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.


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.


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 necesitas alguna razón para no usarla, esta es mi favorita, extraída de este 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 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 tendrán 64 bits de ancho, pero los antiguos prefijos "w" y "l" permanecerán para siempre.


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 :)

Editar: Oh, me di cuenta de que eso es una mentira. También uso "m_" para las variables miembro. p.ej

class { private: bool m_myVar; }


metro

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.


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.


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.


El nombre de la variable debe describir de qué se trata. Los buenos nombres variables hacen que la notación húngara sea inútil.

Sin embargo, a veces usarías la notación húngara además de un buen nombre variable. 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 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ú).

Me ralentizo cuando leo cosas como m_ubScale (¡ sí, te estoy mirando, Liran! ), Ya que tengo que ver su uso (¡no hay comentarios!) Para averiguar qué escala (si es que lo hace) y es tipo de datos (que pasa a ser un punto fijo char). 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 todavía están etiquetados como m_ubWhatever! Confuso, por decir lo menos).

Creo que el húngaro debía ser un aditivo al 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 ¢.


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

mi

para las 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);

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


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


Estaba totalmente en contra de la notación húngara hasta que realmente comencé a leer sobre ello 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.

Mal 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.


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 la mejor notación húngara no es la notación húngara . La notación originalmente estaba destinada a denotar el uso previsto de una variable en lugar de su tipo, pero generalmente se usa para la información de tipo, particularmente para los controles de Formulario (por ejemplo, txtFirstName para un cuadro de texto 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 nounLeardability") y refactorización para cuando el tipo deba ser cambiado (hay "lParams" en la API de Win32 que han cambiado el tipo).

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

  • strFirstName : esto solo 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 ayudarlo 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 nombres de clase en MFC pero realmente no lo necesita. Cuenta es lo suficientemente buena. El nombre en mayúscula 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 (index to array ) - ix es un poco oscuro. Pruebe arrayIndex .
  • usState (cadena insegura para State ) - se parece a "US State". Mejor ir con state _ UnsafeString o algo así. Tal vez incluso envolverlo en una clase UnsafeString para al menos hacerlo seguro.

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.).


pag

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

El húngaro para los tipos de datos está algo pasado de moda. Ahora los IDE pueden decirle cuál es el tipo (en tan solo unos pocos segundos sobre el nombre de la variable), por lo que no es tan importante. Pero tratar un puntero como si sus datos no son buenos, por lo que debe asegurarse de que sea obvio para el usuario lo que es incluso si hace suposiciones que no debería hacer al codificar.


No tiene sentido utilizar el húngaro para indicar los tipos porque el compilador ya lo hace por usted.

Donde húngaro es útil es distinguir entre tipos lógicamente diferentes de variables que tienen el mismo tipo sin procesar. Por ejemplo, si está usando enter para representar coordenadas, puede prefijar x coordenadas con coordenadas x, y con y y distancias con d. Entonces tendrías un código que se parece a

dxHighlight = xStart - xEnd

yHighlight = yLocation + 3

yEnd = yStart + dyHeight

dyCode = dyField * 2

y así. Es útil porque puede detectar errores de un vistazo: si agrega un dy a ay, siempre obtiene un 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

usted sabe de un vistazo que está mal porque agregar un dy y un hacha no tiene sentido. El compilador no pudo detectar esto porque, por lo que puede ver, está agregando un int a un int que está bien.