¿Qué tipo de prefijo usas para las variables miembro?

Question

Sin duda, es esencial para comprender el código dar un prefijo a las variables miembro para que puedan distinguirse fácilmente de las variables "normales".

¿Pero qué tipo de prefijo usas?

He estado trabajando en proyectos donde usábamos metro_ Como prefijo, en otros proyectos usamos solo un guión bajo (lo cual personalmente no me gusta, porque un guión bajo solo no es lo suficientemente demostrativo).

En otro proyecto utilizamos una forma de prefijo largo, que también incluía el tipo de variable. mul_ por ejemplo es el prefijo de a metrovariable de tipo brasa tufirmado yoong.

Ahora déjame saber qué tipo de prefijo utilizas (y explica el motivo).

EDITAR: ¡La mayoría de ustedes parece codificar sin prefijos especiales para variables miembro!¿Esto depende del idioma?De acuerdo con mi experiencia, código C ++ tiende a utilizar un guión bajo o metro_ como prefijo para variables miembro.¿Qué pasa con otros idiomas?

Answer 1

Sin duda, es esencial para comprender el código dar un prefijo a las variables miembro para que puedan distinguirse fácilmente de las variables "normales".

Disputo esta afirmación.No es en absoluto necesario si tienes un resaltado de sintaxis medio decente.Un buen IDE puede permitirle escribir su código en un inglés legible y puede mostrarle el tipo y alcance de un símbolo de otras maneras.Eclipse hace un buen trabajo al resaltar declaraciones y usos de un símbolo cuando el punto de inserción está en uno de ellos.

Editar, gracias delgado:Un buen resaltador de sintaxis como Eclipse también te permitirá usar texto en negrita o cursiva, o cambiar las fuentes por completo.Por ejemplo, me gustan las cursivas para cosas estáticas.

Otra edición:Piénsalo de esta manera;el tipo y alcance de una variable son información secundaria.Debe estar disponible y ser fácil de descubrir, pero no gritarle.Si usas prefijos como m_ o tipos como LPCSTR, eso se convierte en ruido, cuando solo quieres leer la información principal: la intención del código.

Tercera edición:Esto se aplica independientemente del idioma.

Answer 2

No uso ningún prefijo en absoluto.Si corro el peligro de mezclar variables locales o parámetros de métodos con miembros de la clase, entonces el método o la clase son demasiado largos y se benefician de la división.

Esto (posiblemente) no sólo hace que el código sea más legible y algo "fluido", sino que lo más importante Fomenta clases y métodos bien estructurados..Al final, todo se reduce a una cuestión completamente diferente al dilema del prefijo o sin prefijo.

ACTUALIZAR:Bueno, los gustos y las preferencias cambian, ¿no?Ahora uso el guión bajo como prefijo para las variables miembro, ya que ha demostrado ser beneficioso para reconocer variables locales y miembro a largo plazo.Especialmente los nuevos miembros del equipo a veces tienen dificultades cuando no son fácilmente reconocibles.

Answer 3

Ninguno.Solía ​​​​usar guión bajo, pero me disuadieron de hacerlo en un proyecto donde a los demás no les gustó y no se lo perdieron.Un IDE decente o una memoria decente le dirán qué es una variable miembro y qué no.Uno de los desarrolladores de nuestro proyecto insiste en poner "esto". Frente a cada variable de miembro, y lo humorlo cuando estamos trabajando en áreas de código que son nominalmente "suyas".

Answer 4

Subrayar únicamente.

En mi caso, lo uso porque eso es lo que dice el documento de estándares de codificación en mi lugar de trabajo.Sin embargo, no veo el sentido de agregar m_ o alguna cosa húngara horrible al comienzo de la variable.El minimalista 'solo guión bajo' lo mantiene legible.

Answer 5

Es más importante ser consistente que cualquier otra cosa, así que elige algo en lo que tú y tus compañeros de equipo puedan estar de acuerdo y mantenlo.Y si el lenguaje en el que estás codificando tiene una convención, deberías intentar ceñirte a ella.No hay nada más confuso que una base de código que sigue una regla de prefijo de manera inconsistente.

Para c++, hay otra razón para preferir m_ sobre _ además del hecho de que _ a veces antepone palabras clave del compilador.La m significa variable miembro.Esto también le brinda la posibilidad de eliminar la ambigüedad entre las variables locales y otras clases de variables, s_ para estáticas y g_ para globales (pero, por supuesto, no use globales).

En cuanto a los comentarios de que el IDE siempre se ocupará de usted, ¿es realmente el IDE la única forma en que puede ver su código?¿Su herramienta de diferencias tiene el mismo nivel de calidad para resaltar la sintaxis que su IDE?¿Qué pasa con su herramienta de historial de revisiones de control de fuente?¿Ni siquiera envías un archivo fuente a la línea de comando?Los IDE modernos son herramientas de eficiencia fantásticas, pero el código debe ser fácil de leer independientemente del contexto en el que lo leas.

Answer 6

prefiero usar this palabra clave.Eso significa this.data o this->data en lugar de algún nombre dependiente de la comunidad.

Porque:

• con los IDE actuales escribiendo this. ventanas emergentes intellinsense
• es obvio para todos sin saber nombres definidos

Por cierto, prefijar variables con letras para indicar su tipo está desactualizado con buenos IDE y me recuerda esto El artículo de Joel.

Answer 7

Usamos m_ y luego una notación Simonyi ligeramente modificada, tal como dice Rob en una respuesta anterior.Por lo tanto, el prefijo parece útil y m_ no es demasiado intrusivo y es fácil de buscar.

¿Por qué notación?¿Y por qué no simplemente seguir (para .NET) las recomendaciones de notación de Microsoft que se basan en mayúsculas y minúsculas para los nombres?

Última pregunta primero:Como se señaló, VB.NET es indiferente a las mayúsculas y minúsculas.También lo son las bases de datos y (especialmente) los DBA.Cuando tengo que mantener claro el ID de cliente y el ID de cliente (en, por ejemplo, C#), me duele el cerebro.Entonces, la mayúscula es una forma de notación, pero no muy efectiva.

La notación de prefijo tiene valor de varias maneras:

1. Aumenta la comprensión humana del código sin utilizar el IDE.Como en la revisión del código, que todavía encuentro más fácil de hacer inicialmente en papel.
2. ¿Alguna vez escribió T-SQL u otros procesos almacenados RDBMS?Usar notación de prefijo en los nombres de las columnas de la base de datos es REALMENTE útil, especialmente para aquellos de nosotros a quienes nos gusta usar editores de texto para este tipo de cosas.

En resumen, tal vez el prefijo como forma de notación sea útil porque todavía hay entornos de desarrollo donde los IDE inteligentes no están disponibles.Piense en el IDE (una herramienta de software) que nos permite algunos atajos (como la escritura inteligente), pero no comprende todo el entorno de desarrollo.

Un IDE es un Entorno de Desarrollo Integrado de la misma manera que un automóvil es una Red de Transporte:sólo una parte de un sistema más grande.No quiero seguir una convención de "automóviles" como permanecer en carreteras señalizadas, cuando a veces es más rápido simplemente caminar por un terreno baldío.Confiar en el IDE para rastrear la escritura de variables sería como necesitar el GPS del automóvil para caminar por un terreno baldío.Es mejor tener el conocimiento (aunque pueda resultar incómodo tener "m_intCustomerID") en un formato portátil que volver corriendo al coche para cada pequeño cambio de rumbo, por supuesto.

Dicho esto, tanto la convención m_ como la convención "this" son legibles.Nos gusta m_ porque se busca fácilmente y aún permite que la escritura de variables lo siga.Estuvimos de acuerdo en que muchas otras actividades del código marco utilizan un guión bajo simple.

Answer 8

Usando C#, pasé del prefijo 'm_' a solo un guión bajo, ya que 'm_' es una herencia de C++.

Las directrices oficiales de Microsoft le indican que no utilice ningún prefijo y que usar camel-case en miembros privados y caso pascal en miembros públicos.El problema es que esto choca con otra directriz de la misma fuente, que establece que debes hacer que todo el código sea compatible con todos los lenguajes utilizados en .NET.Por ejemplo, VB.NET no hace diferencia entre carcasas.

Entonces solo un guión bajo para mí.Esto también facilita el acceso a través de IntelliSense, y el código externo que solo llama a los miembros públicos no tiene que ver los guiones bajos visualmente desordenados.

Actualizar:No creo que el C# "esto." -prefijo Ayuda al "yo". en VB, que aún verá "me.age" lo mismo que "me.age".

Answer 9

¡Depende del marco que esté usando!Si estoy escribiendo código MFC, entonces uso metro_ y notación húngara.Para otras cosas (que tienden a ser STL/Boost), agrego un sufijo de guión bajo a todas las variables miembro y no me molesto con la notación húngara.

Clase MFC

class CFoo  
{  
private:  
    int m_nAge;  
    CString m_strAddress;  
public:  
    int GetAge() const { return m_nAge; }  
    void SetAge(int n) { m_nAge = n; }  
    CString GetAddress() const { return m_strAddress;  
    void SetAddress(LPCTSTR lpsz) { m_strAddress = lpsz; }  
};

Clase STL

class foo  
{  
private:  
    int age_;  
    std::string address_;  
public:  
    int age() const { return age_; }  
    void age(int a) { age_ = a; }  
    std::string address() const { return address_; }  
    void address(const std::string& str) { address_ = str; }  
};

Ahora bien, esto puede parecer un poco extraño (dos estilos diferentes), pero funciona para mí, y escribir mucho código MFC que no usa el mismo estilo que el propio MFC simplemente se ve feo.

Answer 10

Prefijo las variables miembro con 'm' y los parámetros (en la función) con 'p'.Entonces el código se verá así:

class SomeClass {
    private int mCount;
    ...
    private void SomeFunction(string pVarName) {...}
}

Encuentro que esto le indica rápidamente el alcance básico de cualquier variable; si no hay prefijo, entonces es local.Además, al leer una función no es necesario pensar en lo que se pasa y en qué es solo una variable local.

Answer 11

Realmente depende del idioma.Soy un tipo de C ++ y anteponer todo con un guión bajo es un poco complicado.El lenguaje reserva elementos que comienzan con un guión bajo para la implementación en algunos casos (según el alcance).También existe un tratamiento especial para el doble guión bajo o el guión bajo seguido de una letra mayúscula.Por eso digo que simplemente evite ese lío y simplemente elija algún otro prefijo.'m' está bien en mi opinión.'m_' es un poco excesivo, pero tampoco terrible.Es una cuestión de gustos realmente.

Pero tenga cuidado con esos _leadingUnderscores.Te sorprenderá saber cuántos componentes internos de compiladores y bibliotecas tienen ese nombre, y definitivamente hay lugar para accidentes y confusiones si no eres extremadamente cuidadoso.Solo di no.

Answer 12

La mayor parte del tiempo uso Python.Python requiere que uses self.foo para acceder al atributo foo de la instancia de la clase actual.De esta forma se soluciona el problema de confundir variables locales, parámetros y atributos de la instancia en la que trabajas.
En general, me gusta este enfoque, aunque no me gusta que me obliguen a hacerlo.Por lo tanto, mi forma ideal de hacer esto es no hacerlo y usar alguna forma de acceso a atributos en this o self para recuperar las variables miembro.De esa manera, no tengo que saturar los nombres con metadatos.

Answer 13

Si el idioma soporta el este o A mí palabra clave, luego no use ningún prefijo y en su lugar use dicha palabra clave.

Answer 14

otro truco es convenio de denominación:

Todas las variables miembro se nombran como de costumbre, sin ningún prefijo (o 'esto', es habitual hacerlo en el proyecto)

Pero se diferenciarán fácilmente de las variables locales porque en mi proyecto, esas variables locales siempre se nombran:

• aAlgo:representa un objeto.
• algunoMuchas cosas:lista de objetos.
• esEstado o tieneAlgo:para estado booleano.

Cualquier variable que no comience con 'a', 'algunos' o 'es/tiene' es una variable miembro.

Answer 15

Dado que VB.NET no distingue entre mayúsculas y minúsculas, antepongo a mis variables miembro un guión bajo y mayúsculas y minúsculas al resto del nombre.Escribo en mayúscula los nombres de las propiedades.

Dim _valueName As Integer

Public Property ValueName() As Integer

Answer 16

Estoy con la gente que no usa prefijos.

Los IDE son tan buenos hoy en día que es fácil encontrar la información sobre una variable de un vistazo desde el color de sintaxis, la información sobre herramientas al pasar el mouse y la fácil navegación hasta su definición.

Esto se suma a lo que puede obtener del contexto de la variable y las convenciones de nomenclatura (como lowerCamelCase para variables locales y campos privados, UpperCamelCase para propiedades y métodos, etc.) y cosas como "hasXXXX" e "isXX" para valores booleanos.

No he usado prefijos durante años, pero solía ser un "esto". Monstruo prefijo, pero me he ido a menos que sea absolutamente necesario (gracias, Resharper).

Answer 17

Soy raro y prefijo las variables miembro con iniciales del nombre de la clase (que está en formato camel).

TGpHttpRequest = class(TOmniWorker)
strict private
  hrHttpClient  : THttpCli;
  hrPageContents: string;
  hrPassword    : string;
  hrPostData    : string;

La mayoría de la gente de Delphi simplemente usa F.

TGpHttpRequest = class(TOmniWorker)
strict private
  FHttpClient  : THttpCli;
  FPageContents: string;
  FPassword    : string;
  FPostData    : string;

Answer 18

un solo _ Se utiliza únicamente como indicador visual.(C#)

• ayuda a los miembros del grupo con intellisense.
• Es más fácil detectar las variables miembro al leer el código.
• Es más difícil ocultar una variable miembro con una definición local.

Answer 19

_ en lugar de this.

yo suelo _ también en lugar de this. porque es solo corta (4 caracteres menos) y es un buen indicador de las variables miembro.Además, al utilizar este prefijo puedes evitar conflictos de nombres.Ejemplo:

public class Person {
  private String _name;

  public Person(String name) {
    _name = name;
  }
}

Compáralo con esto:

public class Person {
  private String name;

  public Person(String name) {
    this.name = name;
  }
}

El primer ejemplo me parece más breve y claro.

Answer 20

Depende un poco del idioma en el que estés trabajando.

En C# puede hacer referencia a cualquier miembro utilizando el prefijo 'este', p.'this.val', lo que significa que no se necesitan prefijos.VB tiene una capacidad similar con 'Yo'.

En los idiomas donde hay una notación incorporada para indicar el acceso de los miembros, no veo el sentido de usar un prefijo.En otros idiomas, supongo que tiene sentido utilizar cualquier convención comúnmente aceptada para ese idioma.

Tenga en cuenta que uno de los beneficios de usar una notación incorporada es que también puede usarla al acceder a propiedades y métodos de la clase sin comprometer sus convenciones de nomenclatura para ellos (lo cual es particularmente importante cuando se accede a miembros no privados).La razón principal para usar cualquier tipo de indicador es como señal de que estás causando posibles efectos secundarios en la clase, por lo que es una buena idea tenerlo cuando uses otros miembros, independientemente de si son un campo/propiedad/método/etc. .

Answer 21

Utilizo el caso camel y subrayo como muchos aquí.Utilizo el guión bajo porque trabajo con C# y me he acostumbrado a evitar la palabra clave "this" en mis constructores.Utilizo variantes con alcance del método en caso de camello para que el guión bajo me recuerde con qué alcance estoy trabajando en ese momento.De lo contrario, no creo que importe, siempre y cuando no intentes agregar información innecesaria que ya es evidente en el código.

Answer 22

Solía ​​​​usar m_ perfix en C++ pero en C# prefiero usar mayúsculas camello para el campo y mayúsculas pascal para su propiedad.

private int fooBar;
public int FooBar
{
  get { return fooBar; }
  set { fooBar = value; }
}

Answer 23

Me gusta m_ pero siempre que se use la convención en el código base, estoy de acuerdo.

Answer 24

Su ejemplo mul_ se dirige hacia la notación húngara de aplicaciones de Charles Simonyi.

Prefiero mantener las cosas simples y por eso me gusta usar m_ como prefijo.

Hacer esto hace que sea mucho más fácil ver dónde tienes que ir para ver la declaración original.

Answer 25

Tiendo a usar m_ en C++, pero no me importaría dejarlo en Java o C#.Y depende del estándar de codificación.Para el código heredado que tiene una combinación de guión bajo y m_, refactorizaría el código a un estándar (dado un tamaño de código razonable)

Answer 26

Yo suelo @.

:D j/k - pero si depende del idioma.Si tiene captadores/definidores, generalmente pongo un _ delante de la variable miembro privada y el captador/definidor tendrá el mismo nombre sin _.De lo contrario, normalmente no uso ninguno.

Answer 27

Para mis propios proyectos utilizo _ como sufijo (como señaló Martin York anteriormente, _ como prefijo está reservado por el estándar C/C++ para implementaciones de compiladores) y i cuando trabajo en Proyectos Symbian.

Answer 28

En Java, una convención común es anteponer las variables miembro con "my" y UseCamelCaseForTheRestOfTheVariableName.

Answer 29

Ninguno si no es necesario, guión bajo simple en caso contrario.Aplica para Python.

Answer 30

Si es realmente necesario anteponer variables miembro, definitivamente preferiría m_ a solo un guión bajo.Encuentro que un guión bajo por sí solo reduce la legibilidad y puede confundirse con palabras reservadas de C++.

Sin embargo, dudo que las variables miembro necesiten alguna notación especial.Incluso ignorando la ayuda del IDE, no es obvio por qué habría confusión entre qué es una variable local y qué es una variable miembro.