c# - programming - ¿Ya son necesarios los prefijos variables("notación húngara")?
namespace naming convention c# (29)
A pesar de que el compilador puede verificar rápida y fácilmente el tipo de variable, los humanos no pueden hacerlo mientras roban una parte del código fuente. Por lo tanto, algunas personas (como yo) prefieren hacer que los nombres de las variables sean un poco más detallados, lo que los hace rápidamente reconocibles como variables globales o de clase, cadena o int, etc.
Puede que no ayude al compilador, pero cuando lee una pieza de código extranjera, seguramente le ahorra tener que buscar cada variable manualmente ...
Como C # está muy tipado, ¿realmente necesitamos prefijar variables?
p.ej
iUserAge
iCounter
strUsername
Solía prefijar en el pasado, pero en el futuro no veo ningún beneficio .
A veces uso un tipo de prefijo donde pName es un parámetro pasado a mi función (note que no prefijo el tipo), oName es local para mi método actual, mName es un miembro de la clase en la que estoy y cName es un constante o estático de solo lectura.
Personalmente, creo que ayuda.
Bueno, para contrarrestar, yo diría que depende. Personalmente estoy en contra de ellos, pero todo se reduce a tu equipo. Cada equipo debe ser responsable de desarrollar su propio conjunto de directrices. Esperemos que eso no incluya la llamada notación húngara, pero realmente debería ser una decisión del equipo. Es posible que encuentre casos en los que desee romper con las pautas de estilo.
Definitivamente no. Como regla general, he llegado a creer que es solo ruido. Si usted es un consultor independiente o su empresa no tiene una guía de estilo completa, IDesign tiene una gran guía. Simplemente busque en el lado derecho de la página y puede D / L la última iteración de su documento estándar de codificación C #.
Steve
Dentro del código y cuando se trabaja con tipos de datos no veo ninguna razón para el uso de la notación húngara.
Pero cuando estoy trabajando con una serie de controles de interfaz de usuario, ya sean cuadros de texto, listas desplegables, grillas o no, me gusta que mi intellisense funcione para mí. Entonces para lograr eso, generalmente hago la identificación del control con un prefijo de "uxSomeControlName". De esta manera, cuando estoy buscando ese cuadro de texto para obtener su valor de texto, todo lo que tengo que hacer es escribir "ux" y se muestran todas las identificaciones de la interfaz de usuario. No es necesario buscar txt, ddl, grd o cualquier otra cosa.
Ahora es esto correcto, si lees lo anterior, no. Pero no quiero sentarme y tratar de recordar una docena o más de nombres de control cuando solo tengo que saber dos letras.
Como dije, esto es solo cuando se trabaja en el frente.
Diría que en la mayoría de los idiomas en estos días que tienen un conjunto limitado de tipos, en particular, ningún concepto de tipos sin firmar, una variable bien nombrada no debería necesitar el prefijo.
En los idiomas que tienen tipos con signo y sin signo, o un montón de tipos similares (por ejemplo, corto, int, largo o Int8, Int16, In32), los prefijos son útiles, a pesar de lo que alguien más haya dicho o diga (y lo harán, ya sabes eso).
El compilador, en el mejor de los casos, dará una advertencia cuando intente mezclar tipos integrales de signos diferentes en expresiones, y esto podría perderse fácilmente si, por ejemplo, configura su IDE para que solo muestre errores (no advertencias) en una compilación de el resumen final (como se puede hacer con Visual Studio). Mezclar letreros en aritmética puede arruinar seriamente su día, por lo que puede ahorrarle a usted o su sucesor un dolor de cabeza y darles una pista. Recuerde: usted no es el único que mirará el código.
El único prefijo que consideraría para C # es un _ para variables de miembros tales como
public class Test
{
private int _id;
}
La notación húngara es fea. La única excepción es con las interfaces, donde la mayoría de las personas piensan que es aceptable.
Linus lo resume bien: "Codificar el tipo de una función en el nombre (llamada notación húngara) tiene daño cerebral; el compilador conoce los tipos de todos modos y puede verificarlos, y eso solo confunde al programador".
La notación húngara ya no es necesaria para identificar tipos de datos como en su ejemplo de cadena, pero aún puede ser útil para identificar características de variables de otras maneras. Aquí hay un buen artículo que habla sobre formas útiles de usar la notación húngara: http://www.joelonsoftware.com/articles/Wrong.html
Aquí hay un extracto
"En la versión de Simonyi de la notación húngara, todas las variables estaban precedidas por una etiqueta en minúscula que indicaba el tipo de cosa que contenía la variable.
Por ejemplo, si el nombre de la variable es rwCol, rw es el prefijo.
Estoy usando la palabra tipo a propósito, allí, porque Simonyi utilizó erróneamente el tipo de palabra en su artículo, y generaciones de programadores entendieron mal lo que quiso decir ".
También usa un ejemplo de cadenas identificativas con el prefijo ''s'' o ''u'' para identificar si son seguras para imprimir o no, de modo que una declaración como print (uSomeString); puede identificarse fácilmente como incorrecto.
Lo que me hace curioso acerca de esta pregunta es el hecho de que los idiomas (C y C ++) donde se introdujo el prefijo (es decir, la notación húngara) también fueron fuertemente tipados. Por lo que sé, fue hecho con el uso de Pascal en Microsoft también. Y parece que también se usó con Mesa, un lenguaje muy tipado con el que el húngaro puede estar familiarizado con [; <].
Siendo ese el caso, es justo abordar la cuestión y considerar (1) qué problema fue el prefijo utilizado para ayudar a resolver y (2) ¿cómo se ha ido ese problema?
Sé que esa no es exactamente una respuesta, pero podría ser más útil que las objeciones generales al uso de los prefijos como anticuados o erróneos.
Los únicos lugares que considero adecuados para doblar los estándares y las variables de prefijo:
nombres de control:
txtWhatever- y veo que no soy el único. Lo bueno es que puedes encontrar cosas como lblName junto a txtName, y no necesitas ir a la dirección NameLabel / NameTextBox.variables de miembro de clase:
_whatever. He probado tanto m_ como ningún prefijo y terminé con un guion bajo simple. m_ es más difícil de escribir y no tener prefijo se vuelve confuso a veces (especialmente durante el mantenimiento, sé que todos ustedes saben su código de memoria al escribirlo)
No encontré ninguna situación coherente, sin embargo, prefijar una variable con su tipo haría que el código fuera más legible.
EDITAR: Leí las directrices de Microsoft. Sin embargo, considero que los estilos de codificación pueden evolucionar y / o "doblarse", según corresponda. Como mencioné anteriormente, encontré el uso del prefijo de subrayado útil por prueba y error, y es ciertamente mejor que usar esto. Lo que sea que esté en todas partes en el código.
Apoyando la teoría de "evolución": en .NET 1.x cuando Microsoft publicó las pautas de codificación, aconsejaron usar Camel Camel para todo, incluso constantes. Ahora veo que han cambiado y aconsejan usar el caso Pascal para campos de solo lectura constantes o públicos.
Además, incluso la biblioteca de clases .NET Framework está actualmente llena de m_ y _ y s_ (intente examinar la implementación con el reflector). Entonces, después de todo, depende del desarrollador, siempre que se conserve la coherencia en todo el proyecto.
Los prefijos son un remanente de los días VB (¡y más antiguos!) Cuando la notación húngara era el rey. Ese ya no es el caso, aunque la comunidad C # ordena cosas como usar un prefijo de Capital I para las interfaces (por ejemplo, ILoadable ).
Las Pautas actuales de Microsoft están aquí .
No, no los necesitamos. Solía seguir esto cuando en los días anteriores, nos vimos obligados a seguir ese tipo de estándar de codificación.
También con Intellisense, la ventana de definición de código y las herramientas de refactorización integradas en VS y otros complementos de terceros como CodeRush express y Refactor Pro, es más fácil trabajar con código sin él.
No, si tus métodos son tan largos que no puedes leer la definición al mismo tiempo que el uso, o el nombre no implica el tipo, entonces tienes problemas de diseño más serios que simplemente nombrar.
Sin embargo, INSISTO que usted prefija los controles con su tipo, como txtName.
No. La notación húngara simplemente agrega ruido innecesario al código y es redundante con la verificación del tipo de compilador.
Nop. ¿ Alguna vez lo necesitamos?
Para una descripción general de buenas convenciones, consulte aquí: http://msdn.microsoft.com/en-us/library/ms229002.aspx
Hay un libro sobre eso en el que explican las razones detrás de cada una de esas convenciones. Muy interesante lectura.
Si bien muchos programadores de hoy en día lo están abandonando, todavía lo usaría en ciertos casos. Éstos son algunos de ellos;
Si mantiene un código que ya lo usa, entonces seguiré usándolo.
Cuando las pautas de estilo de su compañía todavía lo requieren o incluso lo sugieren.
Cuando su documentación tiene una lista simple de variables ordenadas alfanuméricamente, ayuda a agrupar tipos similares.
Si húngaro significa "prefijo con una abreviatura de tipo" como uCount o pchzName, entonces diría que esta práctica es mala y afortunadamente parece estar desapareciendo del uso común.
Sin embargo, todavía creo que los prefijos son muy útiles para el alcance. En mi estudio utilizamos esta convención para las variables de prefijación:
i_ // input-only function parameter (most are these)
o_ // output-only function parameter (so a non-const & or * type)
io_ // bidirectional func param
_ // private member var (c#)
m_ // private member var (c++)
s_ // static member var (c++)
g_ // global (rare, typically a singleton accessor macro)
He encontrado que esto es muy útil. Los prefijos de func param en particular son útiles. Muy dentro de una función, siempre se puede ver de dónde viene esa var a simple vista. Y típicamente copiaremos la var a otra cuando queremos modificarlo o cambiar su significado.
En resumen: los prefijos para los tipos son innecesarios con las herramientas modernas. El IDE se encarga de identificar y verificar esas cosas por usted. Pero los prefijos basados en el alcance son muy útiles para la legibilidad y la claridad.
También hay beneficios secundarios divertidos como con Intellisense. Puede escribir i_ ctrl-space y obtener todos los parámetros de entrada a la función para elegir. O g_ ctrl-space para obtener todos sus singletons. Es un ahorro de tiempo.
Siempre prefijo variables de miembro de instancia con m__ y variables de miembro estático con s_ . He encontrado artículos variables de personas de EM que recomiendan / desalientan el enfoque.
También estoy bastante seguro de haber encontrado el prefijo m_ al buscar en las bibliotecas .NET estándar usando Reflector ...
Una solución a un problema que no existe.
Yo personalmente ya no lo hago, sin embargo, todavía habrá personas que aboguen por el prefijo de alcance.
Voy con Microsoft y uso sus estilos de capitalización para todas las convenciones de nombres. Toda la sección "Pautas de diseño para desarrolladores de bibliotecas de clases", de la que forma parte el enlace, es oro puro, en mi opinión.
Además, me encanta el libro "Pautas de diseño del marco" de Addison Wesley. Cubre todas estas pautas con anotaciones de los miembros del equipo de Microsoft sobre por qué recomiendan lo que proponen y cómo se adopta dentro de la organización.
Sí, si la notación húngara se usó como se pretendía originalmente, en lugar de como fue implementada por Microsoft. Al igual que el ejemplo anterior, que muestra cuadros de texto y etiquetas correspondientes como lblWhatever, txtWhatever. Úselo para definir el uso de la variable, no el tipo. Puede proporcionar información para saber que su número es moneyTotal, lo que me dice más que solo el tipo de datos.
Pero, como se usa comúnmente? No.
La respuesta corta es no. Pero...
Veo el punto de alejarme de la notación húngara, los estándares en nuestra tienda también lo prohíben, pero todavía lo encuentro útil en mis proyectos únicos o pequeños por una razón y una razón solamente: cuando estoy codificando para una una gran cantidad de controles en una web o formulario de ganar, usando HN hace que sea fácil de usar Intellisense, asegúrese de que capture cada uno de los controles durante la codificación.
Si tengo cinco casillas de verificación y todos sus nombres comienzan con chk, al escribir chk me da la lista de cada uno de ellos y puedo elegir fácilmente el que estoy trabajando en ese momento.
Además, a veces me pregunto "¿qué diablos fue esa casilla nombrada de nuevo?" Y tengo que interrumpir y buscar en la página .ASPX nuevamente.
Una de las formas en que me he comprometido es comenzar con HN, y luego, una vez que he obtenido el código principal en un formulario ganador o web completo, mi último paso es hacer un cambio de nombre global para los controles con nombre HN. Esto realmente funcionó bien para mí. YMMV, por supuesto.
Solo lo uso en mi base de datos (PostgreSQL)
t_ for table name
v_ for view name
i_ for index name
trig_ for trigger
sp_ for stored procedure name
p_ for parameter
v_ for variable
c_ for cursor
r_ for record
La notación húngara nunca se usó para mostrar qué tipo de datos era la variable. Fue malentendido sugerir que "str" o "i" se usen para definir implícitamente el tipo. Se suponía que solo mostraba el "tipo" de variable, no el "tipo".
Entonces, para responder a la pregunta, no debería usarse ahora ni debería haberse usado alguna vez en el pasado.
Sé que se ha vinculado, pero vaya al final del artículo de Joel para obtener más información: http://www.joelonsoftware.com/articles/Wrong.html donde habla sobre dónde está el húngaro.
Lo uso todo el tiempo, pero eso podría ser porque utilizo VBA con Access y Excel.
Para mí CountAll es un nombre intCountAll es un nombre con esta diferencia que describe adicionalmente el nombre (nunca destinado a máquinas solo para humanos) como sintCountAll me dice que es static pintCountAll private y gintCountAll global, así que para el propósito lo uso; es muy útil.
- nombres de control es un momento más seguro como en lugar de ControlName Tengo lblControlName, txtControlName, cboControlName, lstControlName etc, así que cuando uso VBA simplemente escribo lst y tengo todos los nombres que necesito para no tener que recordar cuál es el nombre exacto lo que me ahorra mucho tiempo, pero nuevamente esto es principalmente VBA en Access y Excel.
Saludos Emil
La mayoría de los argumentos que veo en contra de la notación húngara mencionan que los editores modernos y los IDE son perfectamente capaces de darle toda la información que necesita saber sobre cada identificador. Lo suficientemente justo.
Pero, ¿qué pasa con el código impreso? ¿No llevas a cabo exámenes de códigos o tutoriales en papel? ¿No usas el código impreso para fines de capacitación? ¿No utiliza fragmentos de código para la ayuda en línea? La notación húngara es extremadamente valiosa en estas ocasiones.
Sigo usando (algún tipo de) notación húngara en todo mi código. Encuentro su ausencia fea y carente de información.
¿Ya son necesarios prefijos variables (húngaros)?
¡NO!
De hecho, las propias pautas de estilo de Microsoft (donde se originó la práctica) ahora lo recomiendan. En particular, consulte la sección sobre Convenciones de nomenclatura general , que incluye el siguiente texto (en negrita, no menos):
No use la notación húngara.