Notación húngara en C#

Question

Antes de usar C#, C++ era mi lenguaje de programación principal. Y la notación húngara está en lo profundo de mi corazón.

Hice algunos pequeños proyectos en C# sin leer un libro de C# u otras pautas sobre el idioma. En esos pequeños proyectos de C# utilicé algo así como

private string m_strExePath; 

Hasta que leí algo de manera que dicho:

No utilice la notación húngara.

¿Por qué? ¿Soy la única persona que tiene m_strExePath o m_iNumber en mi código C#?

Answer 1

No, usted no es el único que lo hace. En general, se acepta que la notación húngara no es la mejor manera de nombrar cosas en C# (el IDE maneja muchos de los problemas que la notación húngara intentó abordar).

Answer 2

Si la notación húngara es profunda en su corazón y el de su equipo y el de su empresa, utilícelo. Ya no se considera una mejor práctica en cuanto a lo que puedo leer en blogs y libros.

Answer 3

Si mantiene el puntero sobre la variable en VS, le dirá qué tipo de variable es, por lo que no hay razón para ir con estos nombres de variables crípticos, especialmente porque las personas que provienen de otros idiomas pueden necesitar mantener el código y será un obstáculo para la lectura fácil.

Answer 4

No eres la única persona, pero diría que es relativamente poco común. Personalmente, no soy partidario de la notación húngara, al menos no en el sentido simple que simplemente repite la información de tipo que ya está presente en la declaración. (Los fanáticos de la notación húngara "verdadera" explicarán la diferencia, nunca me molestó tanto, pero puedo ver su punto. Si usa un prefijo común para, por ejemplo, unidades de longitud frente a unidades de peso, no lo hará accidentalmente asigne una variable de longitud con un valor de peso, aunque ambos pueden ser enteros).

Sin embargo, para miembros privados, puede hacer lo que quiera; acuerde con su equipo cuál debería ser la convención de nomenclatura. El punto importante es que si desea que su API encaje con el resto de .NET, no use la notación húngara en sus miembros públicos (incluidos los parámetros).

Answer 5

Al hacer el diseño de la interfaz de usuario, me pareció muy útil mantener la notación húngara. Los artículos como cuadros de texto, etiquetas y listas desplegables son mucho más fáciles de entender rápidamente y con frecuencia se consiguen repetir nombres de los controles:

lblTitle = Label 
txtTitle = TextBox 
ddlTitle = DropDownList 

Para mí eso es más fácil de leer y analizar. De lo contrario, la notación húngara no encaja debido a los avances en IDE, específicamente Visual Studio.

Además, Joel on Software tiene un excelente artículo relacionado con la notación húngara titulado: Making Wrong Code Look Wrong que hace algunos buenos argumentos para notación húngara.

Answer 6

menos que esté utilizando un editor de texto en lugar de la IDE de VS hay poco valor a la notación húngara y impeeds en vez de mejorar la legibilidad

Answer 7

Una desventaja de la notación húngara es que los desarrolladores suelen cambiar el tipo de variables durante la primera codificación, que requiere que el nombre de la variable también cambie.

Answer 8

Los únicos dos áreas en las que actualmente veo cualquier forma de notación húngara son: variables miembro

• Class, con un subrayado inicial (por ejemplo _someVar)
• WinForms y nombres de control WebForms (btn para botón, lbl de etiqueta etc)

el subrayado inicial de variables miembro parece que está aquí para quedarse con nosotros por un tiempo más largo, pero espero ver la popularidad de Hun Garian en los nombres de control a disminuir.

Answer 9

Joel Spolsky tiene un muy buen article sobre este tema. El resumen rápido es que hay dos tipos de notación húngara que se usan en la práctica.

El primero es "Systems Hungarian" donde especifica el tipo de variable usando un prefijo. Cosas como "str" ​​para cuerda. Esta es una información casi inútil, especialmente porque los IDEs modernos te dirán el tipo de todos modos.

El segundo es "Aplicaciones húngaras" donde especifica el propósito de la variable con un prefijo. El ejemplo más común de esto es usar "m_" para indicar las variables miembro. Esto puede ser extremadamente útil cuando se hace correctamente.

Mi recomendación sería evitar "sistemas húngaros" como la peste pero definitivamente usar "aplicaciones húngaras" donde tenga sentido. Sugiero leer el artículo de Joel. Es un poco largo sin aliento, pero lo explica mucho mejor que pude.

La parte más interesante de este artículo es que el inventor original de la notación húngara, Charles Simonyi, creó "Aplicaciones húngaras", pero su trabajo fue horriblemente malinterpretado y la abominación de "Sistemas húngaros" se creó como resultado.

Answer 10

No son sin duda la única persona, pero espero que eres parte de una tendencia a la baja :)

El problema con la notación húngara es que está tratando de implementar un sistema de tipo a través de las convenciones de nombres. Esto es extremadamente problemático porque es un sistema de tipo con solo verificación humana. Cada ser humano en el proyecto debe aceptar el mismo conjunto de estándares, hacer revisiones rigurosas de los códigos y asegurarse de que a todos los tipos nuevos se les asigna el prefijo correcto y apropiado. En resumen, es imposible garantizar la coherencia con una base de código lo suficientemente grande. En el momento en que no hay consistencia, ¿por qué lo haces?

Además, las herramientas no son compatibles con la notación húngara. Eso podría parecer un comentario estúpido en la superficie, pero considere refactorizar, por ejemplo. Cada refactorización en un sistema de convención de nomenclatura húngaro debe ir acompañada de un cambio de nombre masivo para garantizar el mantenimiento de los prefijos. Los cambios de nombre masivos son susceptibles a todo tipo de errores sutiles.

En lugar de utilizar nombres para implementar un sistema de tipos, solo confíe en el sistema de tipos. Tiene verificación automática y soporte de herramientas. Los nuevos IDE hacen que sea mucho más fácil descubrir el tipo de variable (intellisense, hover tips, etc ...) y realmente eliminan el deseo original de notación húngara.

Answer 11

la notación húngara es un terrible error, en cualquier idioma. No deberías usarlo en C++ tampoco. Nombra tus variables para que sepas para qué sirven. No los nombre para duplicar la información de tipo que el IDE puede proporcionarle de todos modos, y que puede cambiar (y por lo general es irrelevante de todos modos).Si sabe que algo es un contador, entonces no importa si es un int16, 32 o 64. Usted sabe que actúa como un contador, y como tal, cualquier operación que sea válida en un contador debe ser válida. Mismo argumento para las coordenadas X/Y. Son coordenadas. No importa si son flotadores o dobles. Puede ser relevante saber si un valor está en unidades de peso, distancia o velocidad. No importa que sea un flotador).

De hecho, la notación húngara solo apareció como un malentendido. El inventor tenía la intención de que se utilizara para describir el tipo "conceptual" de una variable (¿es una coordenada, un índice, un contador, una ventana?)

Y las personas que leyeron su descripción supusieron que por " escriba "quiso decir el tipo de lenguaje de programación real (int, float, cadena terminada en cero, puntero de char)

Nunca fue la intención, y es una idea horrible. Duplica la información que el IDE puede proporcionar mejor, y que no es tan relevante en primer lugar, ya que lo alienta a programar en el nivel de abstracción más bajo posible.

¿Por qué? ¿Soy la única persona que tiene m_strExePath o m_iNumber en mi código C# ?

No. Lamentablemente no. Dime, ¿qué sería exePath si no fuera una cadena? ¿Por qué, como lector de tu código, necesito saber que es una cadena? ¿No es suficiente saber que es el camino al ejecutable? m_iNumber es simplemente mal nombrado. que número es esto? ¿Para qué sirve? Me acabas de decir dos veces que es un número, pero todavía no sé cuál es el significado del número.

Answer 12

En un lenguaje como C# donde no existen muchas limitaciones en la longitud del nombre variable que alguna vez estuvieron en lenguajes como C y C++, y donde el IDE proporciona soporte excelente para determinar el tipo de variable, la notación húngara es redundante .

El código debe explicarse por sí mismo para que nombres como m_szName puedan ser reemplazados por this.name. Y m_lblName puede ser nameLabel, etc. Lo importante es ser coherente y crear código que sea fácil de leer y mantener: este es el objetivo de cualquier convención de nomenclatura, por lo que siempre debe decidir qué convención usar en base a esto. Siento que la notación húngara no es la más legible o la más fácil de mantener porque puede ser demasiado escueta, requiere una cierta cantidad de conocimiento sobre lo que significan los prefijos, y no es parte del lenguaje y, por lo tanto, difícil de aplicar y difícil de detectar cuando el nombre ya no coincide con el tipo subyacente.

En su lugar, me gusta reemplazar aplicaciones húngaras (prefijos como m_) haciendo referencia a this para los miembros, haciendo referencia al nombre de clase para variables estáticas, y sin prefijo para variables locales. Y en lugar de System Hungarian (incluido el tipo de una variable en el nombre de la variable), prefiero describir para qué es la variable, como nameLabel, nameTextBox, count y databaseReference.

Answer 13

La mayoría de la notación húngara describe qué es la variable (un puntero, o un puntero a un puntero, o el contenido de un puntero, etc.), y a qué apunta (cadena, etc.).

He encontrado muy poco uso para los punteros en C#, especialmente cuando no hay llamadas no administradas/pinvoke. Además, no hay opción de usar void *, por lo que no es necesario que húngaro lo describa.

El único sobrante de húngaro que yo (y la mayoría de los demás en C# land) usa, es para los campos privados anteriores con _, como en _customers;

Answer 14

El valor real en la notación húngara se remonta a la programación C y la naturaleza débilmente tipada de los punteros. Básicamente, en el día, la forma más fácil de hacer un seguimiento del tipo era utilizar el húngaro.

En idiomas como C#, el sistema de tipos te dice todo lo que necesitas saber, y el IDE te lo presenta de una manera muy fácil de usar por lo que simplemente no es necesario utilizar el húngaro.

Como una buena razón para no usarlo, bueno, hay bastantes. En primer lugar, en C# y para ese asunto C++ y muchos otros langause a menudo creas tus propios tipos, entonces ¿cuál sería el húngaro para un tipo "MyAccountObject"? Incluso si puede decidir sobre las notaciones húngaras sensibles, aún hace que el nombre de la variable real sea un poco más difícil de leer porque debe saltear el "LPZCSTR" (o lo que sea) al principio. Sin embargo, es más importante el costo de mantenimiento, ¿qué pasa si comienzas con una Lista y cambias a otro tipo de colección (algo que parece hacer mucho en este momento)? Luego necesita cambiar el nombre de todas sus variables que usan ese tipo, todo sin ningún beneficio real. Si hubiera usado un nombre decente para comenzar, no tendría que preocuparse por esto.

En su ejemplo, lo que si se crea o usa algún tipo más significativo para la celebración de una ruta (Ruta por ejemplo), entonces tienes que cambiar su m_strExePath-m_pathExePath, que es un dolor y en este caso no es realmente muy útil.

Answer 15

En algún momento, es muy probable que tenga una propiedad

public string ExecutablePath { ... } 

(no es que usted debe tratar de evitar las abreviaturas como "exe" también). Siendo ese el caso, su pregunta podría ser entonces discutible la mayor parte del tiempo que se puede utilizar C# de 3.0 auto-propiedades

public string ExecutablePath { get; set; } 

que ahora ya no tiene que llegar a un nombre para la variable almacén de respaldo. Sin nombre, sin pregunta/debate sobre convenciones de nombres.

Obviamente, las propiedades implementadas automáticamente no siempre son apropiadas.

Answer 16

Depende.

¿Es lo suficientemente significativo para agregar la descripción del tipo de datos en la variable/nombre del objeto en su método/clase?

sistema de notación húngara> Aplicaciones notación húngara

Si está diseñando en el lenguaje de procedimientos (por ejemplo, C) que tiene muchas de las variables globales o/y de menor API que se ocupa de los tipos de datos precisos y tamaños (por ejemplo, C's <stdint.h> donde se usan más de 40 anotaciones de tipos de datos diferentes para describir int), la notación húngara del sistema es más útil.

Nótese, sin embargo, muchos programadores modernos considerar la adición de información de tipo en nombre de la variable es abundante ya que muchos de los IDE modernos tienen herramientas muy convenientes (por ejemplo Outline de Eclipse, Symbol Navigator de Xcode, Visual AssistX de Visual Studio, etc.). La notación húngara del sistema fue ampliamente utilizada en las edades más tempranas en la programación (por ejemplo, FORTRAN, C99) cuando la información del tipo no estaba disponible fácilmente como una herramienta de los IDEs.

sistema de notación húngara < Aplicaciones notación húngara

Si está trabajando en la clase de nivel superior o método (por ejemplo, la clase/método de controlador definido por el usuario para su aplicación en C#), notating tipo de datos simple puede no ser lo suficiente como para describir la variable/objeto. Por lo tanto, utilizamos la notación húngara de aplicaciones en este caso.

Por ejemplo, si el propósito de su método es recuperar la ruta ejecutable y mostrar un mensaje de error si no se encuentra, en lugar de observar que es un tipo de string, notamos información más significativa para describir la variable/objeto para que los programadores comprendan mejor el propósito de la variable/obejct:

private string mPathExe; 
private string msgNotFound; 

Answer 17

Se trata de eficiencia. Cuánto tiempo se desperdició asignando el valor incorrecto a una variable. Tener declaraciones de variables precisas se trata de ganar en eficiencia. Se trata de la legibilidad. Se trata de seguir los patrones existentes. Si desea creatividad, haga diseño de interfaz de usuario, haga arquitectura de sistema. Si su programación, debe estar diseñada para que los miembros del equipo trabajen más fácilmente: no la suya. Una ganancia del 2% en eficiencias es una semana adicional cada año. Eso es 40 horas ganadas. Los aumentos de la productividad humana se logran combinando eficiencias.

Answer 18

La notación húngara encontró su primer uso principal con el lenguaje de programación BCPL. BCPL es la abreviatura de Before C Programming Language y es una antigua (diseñada en 1966), lenguaje sin letra donde todo es palabra. En esa situación, la notación húngara puede ayudar con la comprobación de tipo a simple vista.

Muchos años han pasado desde entonces ...

Esto es lo que la última Linux kernel documentation (a partir de 2016) dice (el mío negrita):

que codifica el tipo de una función en el nombre (por lo -llamado húngaro notación) tiene daño cerebral - el compilador conoce los tipos de todos modos y puede comprobar esos, y solo confunde al programador.

Tenga en cuenta también que hay dos tipos de notación húngara:

• sistemas de notación húngara: El prefijo codifica física tipo de datos.

• notación Aplicaciones húngaro: El prefijo codifica lógica tipo de datos.

Sistemas La notación húngara ya no se recomienda debido a la redundancia de verificación de tipo, que a su vez se debe al avance en las capacidades del compilador. Sin embargo, aún puede utilizar aplicaciones de notación húngara si el compilador no verifica los tipos de datos lógicos por usted. Como regla general, la notación húngara es buena si y solo si describe la semántica que no está disponible de otra manera.