practicas - Notación húngara en C#
notacion camello (18)
Al hacer el diseño de la interfaz de usuario, me pareció muy útil mantener la notación húngara. Elementos como cuadros de texto, etiquetas y listas desplegables son mucho más fáciles de entender rápidamente y, a menudo, se repiten los nombres de control:
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: article que presenta algunos buenos argumentos para la notación húngara.
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 # usé algo así como
private string m_strExePath;
Hasta que leí algo de SO que decía:
No use la notación húngara.
¿Entonces por qué? ¿Soy la única persona que tiene m_strExePath o m_iNumber en mi código C #?
Definitivamente no eres la única persona, pero espero que seas 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 mediante convenciones de nomenclatura. 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 usar 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.
Depende.
¿Es lo suficientemente significativo como 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 de notación húngara
Si está diseñando en lenguaje de procedimientos (por ejemplo, C) que tiene muchas variables globales y / o API inferior que trata con tipos de datos y tamaños precisos (por ejemplo, C''s <stdint.h> donde se usan 40+ tipos de datos diferentes para describir int ), la notación húngara del sistema es más útil.
Sin embargo, hay que tener en cuenta que muchos programadores modernos consideran que es abundante la información de tipos en el nombre de la variable, ya que muchos IDE modernos tienen herramientas muy prácticas (por ejemplo, Outline of Eclipse, Symbol Navigator of Xcode, Visual AssistX of Visual Studio, etc.). El sistema de notación húngara fue ampliamente utilizado en las edades más tempranas en la programación (por ejemplo, FORTRAN, C99) cuando la información de tipo no estaba disponible como una herramienta de los IDE.
Notación húngara del sistema <Notación húngara de aplicaciones
Si está trabajando en una clase o método de nivel superior (por ejemplo, clase de controlador / método definido por el usuario para su aplicación C #), notar el tipo de datos simple puede no ser suficiente 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 , anotamos información más significativa para describir la variable / objeto para que los programadores la mejoren. comprender el propósito de la variable / obejct:
private string mPathExe;
private string msgNotFound;
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 tipo te dice todo lo que necesitas saber, y el IDE te presenta esto de una manera muy fácil de usar, por lo que simplemente no hay necesidad de usar 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, ¿qué m_strExePath si creó o usó algún tipo más significativo para mantener una ruta (por ejemplo, Ruta de acceso), entonces necesita cambiar su m_strExePath a m_pathExePath , que es un dolor y en este caso no es realmente muy útil.
En algún momento, es probable que tengas una propiedad
public string ExecutablePath { ... }
(No es que deba tratar de evitar abreviaturas como "Exe" también). Siendo ese el caso, su pregunta podría ser discutible la mayor parte del tiempo, ya que puede usar las propiedades automáticas de C # 3.0
public string ExecutablePath { get; set; }
ya no tiene que encontrar un nombre para la variable de la tienda de respaldo. Sin nombre, sin pregunta / debate sobre convenciones de nombres.
Obviamente, las propiedades implementadas automáticamente no siempre son apropiadas.
En un lenguaje como C # donde no existen muchas limitaciones en la longitud del nombre de la variable que alguna vez estuvieron en lenguajes como C y C ++, y donde el IDE proporciona un soporte excelente para determinar el tipo de una 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 cambio, me gusta reemplazar las aplicaciones húngaras (prefijos como m_) haciendo referencia a this para los miembros, haciendo referencia al nombre de clase para las variables estáticas, y sin prefijo para las 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.
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 artículo fue horriblemente malinterpretado y como resultado se creó la abominación de "Sistemas húngaros".
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., 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) uso, es anteceder campos privados con _ , como en _customers ;
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 ( Lenguaje de programación de Before C) y es un lenguaje antiguo (diseñado en 1966) sin letra en el que todo es una palabra . En esa situación, la notación húngara puede ayudar con la comprobación de tipo a simple vista.
Han pasado muchos años desde entonces ...
Esto es lo que dice la última documentación del núcleo de Linux (a partir de 2016) (en negrita):
La codificación del tipo de función en el nombre (llamada notación húngara) está dañada por el cerebro: el compilador conoce los tipos de todos modos y puede verificarlos , y esto 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 el tipo de datos físicos .
Notación húngara de aplicaciones : el prefijo codifica el tipo de datos lógicos .
La notación húngara de sistemas 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.
La notación húngara es un error terrible, 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. Si usted 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 la gente que leyó su descripción asumió que por "tipo" se refería al tipo de lenguaje de programación real (int, float, cadena terminada en cero, puntero char)
Esa 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.
¿Entonces por qué? ¿Soy la única persona que tiene
m_strExePathom_iNumberen mi código C #?
No, desafortunadamente 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 tiene un mal nombre. ¿Qué 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.
Las únicas dos áreas donde actualmente veo cualquier forma de notación húngara son:
- Variables miembro de la clase, con un guion bajo (ej.
_someVar) - WinForms y nombres de control de WebForms (
btnpara Button,lblpara Label, etc.)
El subrayado inicial de las variables miembro parece que está aquí para quedarse con nosotros por un tiempo más, pero espero ver que disminuya la popularidad del húngaro en los nombres de control.
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 asigna una variable de longitud con un valor de peso, aunque ambos pueden ser enteros).
Sin embargo, para los miembros privados, puede hacer lo que quiera, acuerde con su equipo cuál debería ser la convención de nombres. El punto importante es que si quieres que tu API encaje con el resto de .NET, no uses la notación húngara en tus miembros públicos (incluidos los parámetros).
No, no eres 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).
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.
Si la notación húngara es profunda en tu corazón y el de tu equipo y el de tu compañía, úsala. Ya no se considera una mejor práctica en cuanto a lo que puedo leer en blogs y libros.
Si mantiene el puntero sobre la variable en VS, le dirá qué tipo de variable es, por lo que no hay ninguna 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.
Una desventaja de la notación húngara es que los desarrolladores cambian frecuentemente el tipo de variables durante la codificación temprana, lo que requiere que el nombre de la variable también cambie.
a menos que esté usando un editor de texto en lugar del VS IDE, la notación húngara tiene poco valor e impide en lugar de mejorar la legibilidad