tag remarks generate example c# field naming-conventions hungarian-notation

generate - remarks c#



¿Por qué no debería prefijar mis campos? (25)

Nunca he sido fanático de la notación húngara, siempre me ha parecido bastante inútil a menos que estés haciendo una programación realmente de bajo nivel, pero en todos los proyectos de C ++ en los que trabajé se aplicó algún tipo de política de notación húngara, y con ella, el uso de algunos prefijos "no realmente húngaros" como m_ para campos, s_ para estática, g_ para globales, etc.

Pronto me di cuenta de lo inútil que era en C # y poco a poco empecé a abandonar todos mis viejos hábitos ... pero la cosa ''m_''. Todavía uso el prefijo m_ en campos privados porque realmente me resulta muy útil poder distinguir entre parámetros, locales y campos.

La convención de nombres para la página de campos en MSDN dice que no debería, pero no dice por qué (la forma en que, por ejemplo, las convenciones de Google generalmente tienden a racionalizar sus recetas).

¿Hay razones por las que no debería o es solo una cuestión de estilo? Si es el último, ¿los prefijos generalmente se consideran un estilo malo y puedo esperar reacciones negativas de otras personas que trabajan en la base del código?

A menos que esté atascado con vi o Emacs para editar el código, mi IDE se ocupa de la visualización diferencial de los miembros para mí, así que rara vez uso convenciones especiales. Eso también se aplica a las interfaces de prefijación con I o las clases con C.

Alguien, por favor, explique el estilo .NET del prefijo I en las interfaces. :)

Aquí hay algunas razones para usar _ (y no m_).

(1) Muchos BCL lo hacen a pesar de la guía de nombres de MS. (Vea su blog .) Esos tipos escriben el marco, por lo que tienen buenos hábitos que vale la pena copiar. Algunos de los códigos de ejemplo más útiles en MSDN están escritos por ellos, por lo que usan la convención de subrayado. Es un estándar de la industria de facto.

(2) Un único guión bajo es una manera notable pero discreta de eliminar la ambigüedad del método y las variables de nivel de clase simplemente leyendo la fuente. Ayuda a las personas a entender el código nuevo (o antiguo) de un vistazo al leerlo. Sí, puedes pasar el mouse para ver esto en un IDE, pero no debemos forzarlo. Es posible que desee leerlo en un editor de texto, o me atrevo a decirlo, en papel.

(3) Algunos dicen que no necesita ningún prefijo, ya que los métodos serán cortos y, más adelante, si es necesario, puede cambiar el campo a una propiedad implementada automáticamente. Pero en el mundo real los métodos son tan largos como deben ser, y existen diferencias importantes entre campos y propiedades (por ejemplo, serialización e inicialización).

Nota al pie: La "m" para el miembro en m_ es redundante en nuestro uso aquí, pero en minúscula porque una de las ideas en muchas de estas convenciones de nomenclatura antiguas era que los nombres de tipo comenzaban con mayúsculas y los nombres de instancia comenzaban con minúsculas. Eso no se aplica en .NET por lo que es doblemente redundante. También la notación húngara a veces era útil con viejos compiladores de C (por ejemplo, enteros o fundición de punteros y aritmética), pero incluso en C ++ su utilidad disminuía cuando se trataba de clases.

Como algunos han aludido, las directrices de MS dicen:

No use un prefijo para nombres de campo. Por ejemplo, no use g_ o s_ para distinguir campos estáticos versus campos no estáticos.

Estoy de acuerdo con esto. los prefijos hacen que su código se vea feo y pierda espacio con caracteres sin importancia. Una vez dicho esto, a menudo es común usar campos para respaldar propiedades donde tanto el campo como la propiedad tendrían el mismo nombre (con el campo privado siendo camel case y la propiedad siendo pascal case). En VB, esto no funciona, ya que VB no distingue entre mayúsculas y minúsculas. En este escenario, recomiendo el uso de un único prefijo _. Ni mas ni menos. Simplemente se ve más limpio, en mi humilde opinión.

Como dice John Kraft, no hay una respuesta "correcta". MattJ es lo más cercano: siempre debe seguir las pautas de estilo de su empresa. Cuando en Roma, y ​​todo eso.

En cuanto a mi opinión personal, dado que es necesaria aquí, voto que abandones m_ completo.

Creo que el mejor estilo es aquel en el que todos los miembros son PascalCased , independientemente de la visibilidad (eso significa incluso private miembros private ), y todos los argumentos se camelCased . No rompo este estilo.

Puedo entender el deseo de prefijar el campo de la tienda de respaldo de propiedad; después de todo, debe diferenciar entre el campo y la propiedad, ¿verdad? Estoy de acuerdo, debes hacerlo. Pero usa una corrección posterior.

En lugar de m_MyProperty (o incluso _MyProperty , que he visto e incluso promocionado alguna vez), use MyPropertyValue . Es más fácil de leer y comprender y, lo que es más importante, está cerca del nombre de la propiedad original en intellisense.

En definitiva, esa es la razón por la que prefiero un postfijo. Si quiero acceder a MyPropertyValue usando intellisense, (normalmente) escriba " My <down-arrow> <tab> ", ya que para entonces está lo suficientemente cerca como para que solo MyProperty y MyPropertyValue estén en la lista. Si quiere acceder a m_MyProperty usando intellisense, tendrá que escribir " m_My <tab> ".

Se trata de la economía del golpe de teclado, en mi opinión.

Con herramientas como el reafilamiento, realmente no hay motivo para los prefijos. Además, si escribe métodos cortos, debería poder decir realmente rápidamente de dónde viene la var. Finalmente, supongo que realmente no vería la necesidad de diferenciar entre una estática o no, ya que de nuevo el resharper se alineará en rojo si intenta hacer algo que no puede. Incluso sin resharper, es probable que el compilador lo guarde.

Cuando deberías:

  • Cuando las pautas de codificación de su proyecto dicen que debería

Cuando no deberías:

  • Cuando las pautas de codificación de su proyecto dicen que no debería

Si todavía no tienes ninguna guía, puedes elegir lo que tú o tu equipo quieran y con lo que se sientan más cómodos. Personalmente cuando codigo C ++ tiendo a usar m_ para miembros, ayuda. Cuando codifico en otros idiomas, particularmente aquellos sin clases verdaderas (como Javascript, Lua) no lo hago.

En resumen, no creo que haya una manera "correcta" y "incorrecta".

El beneficio de esa notación en C / C ++ fue facilitar la visualización del tipo de símbolo sin tener que buscar la declaración. Estos estilos aparecieron antes de la llegada de Intellisense y "Ir a Definición" - a menudo teníamos que ir a la búsqueda de la declaración en quién sabe cuántos archivos de encabezado. En un proyecto grande, esto podría ser una molestia significativa, lo cual fue suficientemente malo cuando se mira el código fuente C, pero aún peor cuando se hace análisis forense usando un ensamblaje mixto + código fuente y una pila de llamadas en bruto.

Cuando nos enfrentamos con estas realidades, el uso de m_ y todas las demás reglas húngaras comienza a tener sentido, incluso con la sobrecarga de mantenimiento, debido a cuánto tiempo se ahorraría simplemente buscando el tipo de símbolo al buscar un código desconocido. Ahora, por supuesto, tenemos Intellisense y "Ir a definición", por lo que la principal motivación de ahorro de tiempo de esa convención de nombres ya no existe. No creo que tenga mucho sentido hacer eso más, y generalmente trato de seguir las directrices de la biblioteca .NET para ser coherente y posiblemente obtener un poco más de soporte de herramientas.

Estoy seguro de que voy a ser despedido por esto, pero que así sea.

Se llama directrices de la biblioteca .NET de Microsoft, pero en realidad se trata de las opiniones de Brad Adams: hay otras vistas con razones válidas.

La gente tiende a ir con la vista de la mayoría en lugar de tener buenas razones sólidas para un estilo específico.

El punto importante es evaluar por qué se usa un estilo específico y por qué es preferible a otro estilo; en otras palabras, tener una razón para elegir un estilo, no solo porque todos dicen que es lo que se debe hacer, piense por sí mismo.

La razón básica para no utilizar el estilo antiguo húngaro era el uso de abreviaturas que eran diferentes para cada equipo y difíciles de aprender; esto se resuelve fácilmente al no abreviar.

A medida que las herramientas de desarrollo disponibles cambian, el estilo debe cambiar a lo que sea más lógico, pero tiene una razón sólida para cada elemento de estilo.

A continuación están mis pautas de estilo con mis razones: siempre estoy buscando formas de mejorar mi estilo para crear un código más confiable y fácil de mantener.

Convención de Nombramiento Variable

Todos tenemos nuestra opinión sobre las convenciones de nomenclatura variable. Hay muchos estilos diferentes que ayudarán a producir código de calidad de fácil mantenimiento; cualquier estilo que admita la información esencial básica sobre una variable está bien. El criterio para una convención de nomenclatura específica debe ser que ayude a producir código que sea confiable y fácil de mantener. Los criterios que no deberían usarse son: Es feo Microsoft (es decir, Brad Adams) dice que no use ese estilo: Microsoft no siempre produce el código más confiable, solo mire los errores en Expression Blend. Al leer el código, es muy importante que el nombre de una variable transmita instantáneamente tres hechos esenciales sobre la variable: su alcance es una forma de entender claramente en qué se usa. Alcance: Microsoft recomienda confiar totalmente en IntelliSense. IntelliSense es increíble; sin embargo, uno simplemente no pasa el mouse sobre cada variable para ver su alcance y tipo. Asumir que una variable está en un alcance que no es puede causar errores significativos. Por ejemplo, si una variable de referencia se pasa como un parámetro y se modifica en el alcance local, ese cambio se mantendrá después de que el método retorne, lo que puede no ser deseado. Si un campo o una variable estática se modifica en el ámbito local, pero uno piensa que se trata de una variable local, podría producirse un comportamiento inesperado. Por lo tanto, es extremadamente importante poder simplemente mirar una variable (no sobre el mouse) y conocer instantáneamente su alcance.

Se sugiere el siguiente estilo para indicar el alcance; sin embargo, cualquier estilo está perfectamente bien siempre y cuando indique clara y consistentemente el alcance de la variable: m_ variable de campo p_ parámetro pasado a un método s_ variable variable local tipo: Se pueden producir errores graves si uno cree que están trabajando con un tipo específico cuando en realidad están trabajando con un tipo diferente; de ​​nuevo, simplemente no pasamos el mouse sobre cada variable para determinar su tipo, solo asumimos que sabemos cuál es su tipo y así es como se crean los errores.

Abreviaturas: las abreviaturas son malas porque pueden significar cosas diferentes para diferentes desarrolladores. Un desarrollador puede pensar que una "minúscula" en minúscula significa cadena, mientras que otra puede pensar que significa entero con signo. Las abreviaturas son un signo de codificación diferida. Tómese un poco más de tiempo e ingrese el nombre completo para que quede claro para el desarrollador que debe mantener el código. Por ejemplo, la diferencia entre "str" ​​y "cadena" es de solo tres caracteres; no hace falta mucho más esfuerzo para que el código sea fácil de mantener.

Las abreviaturas comunes y claras para los tipos de datos incorporados solo son aceptables, pero deben estar estandarizadas dentro del equipo.

Código de autoedición: Agregar una descripción clara a un nombre de variable hace que sea muy fácil para otro desarrollador leer y comprender el código: haga que el nombre sea tan comprensible que el gerente del equipo pueda leer y comprender el código sin ser un desarrollador.

Orden de las partes de los nombres de las variables: el orden recomendado es la descripción del tipo de alcance porque: IntelliSense agrupará todos los ámbitos similares y dentro de cada alcance IntelliSense agrupará todos los tipos similares, lo que facilita las búsquedas: intente encontrar una variable de otra forma. Lo hace muy fácil para ver y entender el alcance y para ver y entender el tipo Es un estilo bastante común y fácil de entender Pasará FxCop

Ejemplos: Estos son algunos ejemplos: m_stringCustomerName p_stringCustomerDatabaseConnectionString intNumberOfCustomerRecords o iNumberOfCustomerRecords o integerNumberOfCustomerRecords Estas sencillas reglas mejorarán significativamente la confiabilidad y la capacidad de mantenimiento del código.

Estructura de control Declaraciones de línea única Todas las estructuras de control (if, while, for, etc.) sentencias de línea única siempre deben incluirse con llaves porque es muy fácil agregar una nueva instrucción sin darse cuenta de que una instrucción dada pertenece a una estructura de control que rompa la lógica del código sin generar ningún error de tiempo de compilación.

Envolvimiento de excepciones del método Todos los métodos deben ser envueltos con un try-catch externo que atrape, proporcione un lugar para recuperar, identificar, localizar, registrar y tomar la decisión de lanzar o no. Es la excepción inesperada la que hace que nuestras aplicaciones se cuelguen: al incluir cada método que atrapa todas las excepciones no controladas, garantizamos la identificación y el registro de todas las excepciones, y evitamos que nuestra aplicación se cuelgue. Se necesita un poco más de trabajo, pero los resultados bien valen la pena.

Sangría La sangría no es un problema importante; sin embargo, se sugieren cuatro espacios y no se usan pestañas. Si se imprime el código, la primera pestaña de la impresora generalmente tiene un valor predeterminado de 8 espacios. Diferentes desarrolladores tienden a usar diferentes tamaños de pestañas. El código de Microsoft generalmente tiene un espacio de 4 sangrías por lo que si uno usa un código de Microsoft y utiliza un espacio distinto a 4, entonces deberá reformatear el código. Cuatro espacios lo hacen fácil y consistente.

Hay una diferencia importante entre C ++ y C #: Soporte de herramientas. Cuando sigue las pautas establecidas (o variaciones comunes), obtendrá un nivel profundo de soporte de herramientas que C ++ nunca tuvo. Seguir los estándares permite que las herramientas realicen operaciones de refactorización / cambio de nombre más profundas de lo que de lo contrario serían capaces. Resharper hace esto. Así que quédese con uno de los estándares establecidos.

He experimentado con m_, s_, simplemente _, y sin prefijo en absoluto. Me he decidido a usar simplemente _ para todas las variables estáticas y de instancia. No me parece importante distinguir las variables estáticas de las variables de instancia. En teoría, suena bien, en la práctica no crea un problema.

Un compañero de trabajo hizo una vez un argumento convincente para eliminar todos los prefijos, lo probamos en un proyecto y funcionó mejor de lo que esperaba. Lo llevé a mi próximo proyecto y me molestó que "interfiera" con Intellisense. Cuando tienes la siguiente situación

int foo; public int Foo { get { return foo; } }

Comenzar a escribir foo sugerirá tanto la variable de instancia como la propiedad. Al fijar la variable con un guión bajo se elimina la molesta sugerencia doble, así que volví a usar simplemente _.

La característica de propiedad implementada automáticamente en C # 3.0 crea menos necesidad de esta convención de una manera u otra. En lugar de escribir

string m_name; public string Name { get { return m_name; } }

o

string _Name; public string Name { get { return _Name; } }

(o cualquier otra convención), ahora puede escribir

public string Name { get; private set; }

Como ya no necesita la variable explícita del almacén de respaldo, ya no tiene que encontrar un nombre para ella; evitando así toda esta discusión.

Obviamente, este argumento no se aplica cuando realmente necesita un almacén de respaldo explícito como para realizar la validación.

La mejor manera es acordar un estándar con sus colegas y mantenerlo. No necesariamente tiene que ser el método que funcione mejor para todos, solo acordar un método es más importante que el método en el que realmente está de acuerdo.

Lo que elegimos para nuestro estándar de código es usar _ como prefijo para las variables miembro. Una de las razones es que hace que sea más fácil encontrar las variables locales en el intellisense.

Antes de aceptar ese estándar, utilicé otro. No this.memberVariable ningún prefijo y escribí this.memberVariable en el código para mostrar que estaba usando una variable miembro.

Con la característica taquigrafía en C # 3, encuentro que utilizo variables mucho menos explícitas para los miembros.

Lo más parecido a las directrices oficiales es StyleCop , una herramienta de Microsoft que puede analizar automáticamente sus archivos fuente y detectar violaciones del estilo de codificación recomendado, y puede ejecutarse desde Visual Studio y / o compilaciones automáticas como MSBuild.

Lo usamos en nuestros proyectos y ayuda a que el estilo del código y el diseño sean más consistentes entre los desarrolladores, aunque se advirtió que le tomó bastante tiempo acostumbrarse.

Para responder a su pregunta, no permite ninguna notación húngara, ni ningún prefijo como m_ (de hecho, no permite el uso de guiones bajos).

Me gusta el prefijo de barra inferior para los campos de miembros. En general me gusta porque de esa manera, todos mis campos de miembros se muestran alfabéticamente antes de mis métodos en la barra del asistente en la parte superior de la pantalla.

No uso ese estilo por más tiempo. Fue desarrollado para ayudarlo a ver rápidamente cómo se usaban las variables. Los entornos de desarrollo más nuevos le permiten ver esa información pasando el mouse sobre la variable. La necesidad se ha ido si usa esas herramientas más nuevas.

Nunca hago esto y la razón por la cual es que [trato de] mantener mis métodos cortos. Si puedo ver todo el método en la pantalla, puedo ver los parámetros, puedo ver a los lugareños y puedo decir qué pertenece a la clase y qué es un param o un local.

Normalmente llamo mis params y locales usando una notación particular, pero no siempre. No soy nada si no inconsistente. Confío en el hecho de que mis métodos son cortos y trato de evitar que hagan X, Y y Z cuando deberían estar solo haciendo X.

De todos modos, esos son mis dos centavos.

Nunca uso verrugas húngaras cada vez que tengo la opción. Es un tipeo extra y no transmite ninguna información significativa. Cualquier IDE correcto (y defino "bueno" en función de la presencia de esta característica, entre otras) le permitirá tener diferentes resaltados de sintaxis para miembros estáticos, miembros de instancias, funciones de miembros, tipos, etc. No hay razón para desordenar su código con información que puede ser proporcionada por el IDE. Este es un corolario para no saturar su código con código viejo comentado, porque su sistema de control de versiones debería ser responsable de esas cosas.

Prefiero marcar campos de respaldo de propiedades (aunque como ya se mencionó, .NET 3.0+ reduce la necesidad gracias a Automatic Properties) con guiones bajos pero no la "m". Por un lado, los coloca en la parte superior de la lista de InteliSense cuando los utilizo.

Debo admitir que necesito repasar las pautas en MSDN, las cosas pueden cambiar tan rápido en estos días.

Ser funcional.

  • No use variables globales.
  • No use variables estáticas.
  • No use variables miembro.

Si realmente tiene que hacerlo, pero solo si realmente tiene que hacerlo, use una y solo una variable para acceder a su aplicación / entorno.

Si no está codificando bajo una guía particular, debe seguir usando su notación m_ real y cambiarla si las pautas de codificación del proyecto lo indican.

Siempre prefijo las variables miembro con m_ y las variables estáticas con s_ por las mismas razones que usted indica. Algunas personas prefijan las variables miembro con un guión bajo, pero siempre me pareció un poco extraño (pero eso es solo una preferencia personal).

La mayoría de las personas con las que trabajo usan el prefijo m_ / s_. Realmente no creo que importe demasiado lo que usas, siempre y cuando seas consistente.

También podría haber alguna idea que se pueda deducir de los Estándares de codificación de C ++ ( Sutter, Herb y Alexandrescum Andrei , 2004). El ítem # 0 se titula "No te preocupes por lo pequeño. (O: sé lo que no estandarizar)".

Tocan esta pregunta específica un poco al decir "Si no puede decidir sobre su propia convención de nombres, intente ... variables de miembros privados como This_ ..." (Recuerde que el uso del subrayado principal está sujeto a reglas muy específicas en C ++ )

Sin embargo, antes de llegar allí, enfatizan un cierto nivel de coherencia "... lo importante no es establecer una regla, sino ser coherentes con el estilo que ya se utiliza en el archivo ..."

Yo nunca los uso. Alienta la codificación descuidada. Las pautas de codificación de MSDN, ahí es donde están.

a lo que estoy acostumbrado es a que las propiedades privadas tienen un pequeño underscone f.ex "string _name". el público tiene "Nombre". y las variables de entrada en los métodos obtuvieron la letra pequeña "void MyMethod (string name)".

si tienes const estático a menudo se escribe con letras grandes. static const MYCONST = "hmpf" .