coding style - que - ¿Qué tipo de prefijo usas para las variables miembro?
que es un metodo en programacion (30)
Sin duda, es esencial para entender el código dar a las variables miembro un prefijo para que puedan distinguirse fácilmente de las variables "normales".
Pero, ¿qué tipo de prefijo usas?
He estado trabajando en proyectos en los que usamos m_ como prefijo, en otros proyectos usamos solo un guión bajo (que personalmente no me gusta, porque un guión bajo no es lo suficientemente demostrativo).
En otro proyecto, utilizamos una forma larga de prefijo, que también incluía el tipo de variable. mul_ por ejemplo es el prefijo de una variable de árbol de tipo u nsigned l ong.
Ahora avíseme qué tipo de prefijo usa (y proporcione una razón para ello).
EDITAR: ¡ La mayoría de ustedes parece codificar sin prefijos especiales para las variables de miembro! ¿Esto depende del idioma? Desde mi experiencia, el código C ++ tiende a usar un guión bajo o m_ como un prefijo para las variables miembro. ¿Qué hay de otros idiomas?
¡Depende de qué marco estoy usando! Si estoy escribiendo código MFC, entonces uso m_ y notación húngara. Para otras cosas (que tiende a ser STL / Boost), agrego un sufijo de subrayado 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 esto puede parecer un poco extraño, dos estilos diferentes, pero me funciona, y escribir mucho código MFC que no usa el mismo estilo que MFC solo se ve feo.
Como VB.NET no distingue entre mayúsculas y minúsculas, prefijo mis variables miembro con un guión bajo y camello el resto del nombre. Capitalizo los nombres de las propiedades.
Dim _valueName As Integer
Public Property ValueName() As Integer
Depende en qué idioma estés trabajando.
En C # puede hacer referencia a cualquier miembro que use el prefijo ''this'', por ejemplo ''this.val'', lo que significa que no se necesitan prefijos. VB tiene una capacidad similar con ''Yo''.
En los idiomas en los que existe una notación incorporada para indicar el acceso de los miembros, no veo el sentido de usar un prefijo. En otros idiomas, creo que tiene sentido usar cualquiera que sea la convención comúnmente aceptada para ese idioma.
Tenga en cuenta que uno de los beneficios de utilizar una notación incorporada es que también puede usarlo cuando accede a propiedades y métodos en la clase sin comprometer sus convenciones de nomenclatura (lo cual es particularmente importante cuando se accede a miembros no privados). La razón principal para usar cualquier tipo de indicador es como una señal de que estás causando posibles efectos secundarios en la clase, por lo que es una buena idea tenerla cuando uses otros miembros, independientemente de si son un campo / propiedad / método / etc. .
En Java, una convención común es preceder a las variables miembro con "my" andUseCamelCaseForTheRestOfTheVariableName.
Es más importante ser constante que nada, así que elige algo en lo que tú y tus compañeros puedan ponerse de acuerdo y aferrándote a él. Y si el idioma que está codificando tiene una convención, debe intentar mantenerlo. Nada es más confuso que una base de código que sigue una regla de prefijo de forma inconsistente.
Para c ++, hay otra razón para preferir m_ sobre _ además del hecho de que _ a veces prefija las palabras clave del compilador. El m representa la variable miembro. Esto también le da la capacidad de desambiguar entre los locales y las otras clases de variables, s_ para static y g_ para global (pero, por supuesto, no use globales).
En cuanto a los comentarios de que el IDE siempre se encargará de ti, ¿el IDE es realmente la única forma en que estás mirando tu código? ¿Su herramienta diff tiene el mismo nivel de calidad para hilighting de sintaxis que su IDE? ¿Qué hay de la herramienta de historial de revisiones de control de origen? ¿Nunca catás un archivo fuente a la línea de comando? Los IDE modernos son fantásticas herramientas de eficiencia, pero el código debe ser fácil de leer, independientemente del contexto en el que lo estés leyendo.
Estoy con las personas que no usan prefijos.
Los IDEs son tan buenos hoy en día que es fácil encontrar la información sobre una variable de un vistazo, desde la coloración de la sintaxis, la información sobre herramientas del mouse y la navegación fácil hasta su definición.
Esto se suma a lo que puede obtenerse del contexto de las convenciones de variables y nombres (como lowerCamelCase para variables locales y campos privados, UpperCamelCase para propiedades y métodos, etc.) y cosas como "hasXXXX" y "isXX" para booleanos.
No he usado prefijos durante años, pero solía ser un "esto". monstruo del prefijo, pero me he marchado a menos que sea absolutamente necesario (gracias, Resharper).
La mayoría de las veces, uso Python. Python requiere que use self.foo para acceder al atributo foo de la instancia de la clase actual. De esta forma, se resuelve el problema de confundir variables locales, parámetros y atributos de la instancia en la que trabaja.
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 este o en uno mismo para obtener las variables miembro. De esa forma, no tengo que ocupar los nombres con metadatos.
Ninguna. Solía usar el guión bajo, pero me convencieron de un proyecto en el que a los demás no les gustó y no se lo perdieron. Un IDE decente o una memoria decente le dirá qué es una variable miembro y qué no. Uno de los desarrolladores de nuestro proyecto insiste en poner "esto". frente a cada variable miembro, y lo humorizamos cuando estamos trabajando en áreas de código que son nominalmente "suyas".
Ninguno si no es necesario, solo guión bajo. Aplica para Python.
Otro truco es nombrar la convención :
Todas las variables miembro se nombran como de costumbre, sin ningún prefijo (o ''this.'' Es lo habitual en el proyecto)
Pero se diferenciarán fácilmente de la variable local porque en mi proyecto, esas variables locales siempre se nombran:
- algo: representa un objeto.
- algunos ManyThings: lista de objetos.
- es AState o tiene SomeThing: para estado booleano.
Cualquier variable que no empiece por ''a'', ''some'' o ''is / has'' es una variable miembro.
Para mis propios proyectos, uso _ como un postfijo (como Martin York mencionó anteriormente, _ como un prefijo está reservado por el estándar C / C ++ para las implementaciones del compilador) y yo cuando trabajo en proyectos Symbian .
Prefiero usar this palabra clave. Eso significa this.data or this->data lugar de algún nombre dependiente de la comunidad.
Porque
- con IDEs hoy en día escribiendo
this.popups intellinsense - es obvio para todos sin saber nombres definidos
Por cierto, las variables prefijadas con letras para denotar su tipo están obsoletas con IDEs buenos. Y me recuerda este artículo de Joel
Realmente depende del idioma. Soy un chico de C ++, y prefijar todo con guion bajo es un poco complicado. El lenguaje reserva cosas que comienzan con guiones bajos para la implementación en algunos casos (dependiendo del alcance). También hay un tratamiento especial para el guión bajo doble, o subrayado seguido de una letra mayúscula. Entonces digo simplemente evitar ese lío y simplemente elegir algún otro prefijo. ''m'' está bien IMO. ''m_'' es demasiado, pero tampoco terrible. Una cuestión de gusto realmente.
Pero ten cuidado con esos "lideresantes". Te sorprenderá la cantidad de componentes internos de compilador y biblioteca, y definitivamente hay espacio para accidentes y confusión si no eres extremadamente cuidadoso. Solo di no.
Si es realmente necesario prefijar las variables miembro, definitivamente preferiría m_ solo un guión bajo. Encuentro que un guión bajo por sí mismo reduce la legibilidad y puede confundirse con palabras reservadas de C ++.
Sin embargo, dudo que las variables miembro necesiten una notación especial. Incluso ignorando la ayuda de IDE, no es obvio por qué habría confusión entre lo que es una variable local y lo que es miembro.
Solía usar m_ perfix en C ++, pero en C # prefiero usar camel case para el campo y pascal case para su propiedad.
private int fooBar;
public int FooBar
{
get { return fooBar; }
set { fooBar = value; }
}
Soy raro y prefijo las variables miembro con las iniciales del nombre de la clase (que es camel-cased).
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;
Su ejemplo de mul_ se dirige hacia la notación húngara de aplicaciones de Charles Simonyi.
Prefiero mantener las cosas simples y es por eso que me gusta usar m_ como el prefijo.
Hacer esto hace que sea mucho más fácil ver a dónde tiene que ir para ver la declaración original.
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 mezcla de guión bajo y m_, refactorizaría el código a un estándar (dado un tamaño de código razonable)
Un solo _ usado solo como un indicador visual. (DO#)
- ayuda a los miembros del grupo con intellisense.
- es más fácil detectar las variables miembro al leer el código.
- más difícil de ocultar una variable miembro con una definición local.
Usamos m_ y luego una notación Simonyi ligeramente modificada, como dice Rob en una respuesta anterior. Por lo tanto, el prefijo parece útil y m_ no es demasiado intrusivo y fácil de buscar.
¿Por qué la notación en absoluto? ¿Y por qué no simplemente seguir (para .NET) las recomendaciones de notación de Microsoft que se basan en el uso de nombres?
Última pregunta primero: como se señaló, VB.NET es indiferente a la carcasa. También lo son las bases de datos y (especialmente) los DBA. Cuando tengo que mantener el ID de cliente y el ID de cliente (por ejemplo, C #), me duele el cerebro. Entonces, el revestimiento es una forma de notación, pero no muy efectiva.
La notación de prefijo tiene valor de varias maneras:
- Aumenta la comprensión humana del código sin usar el IDE. Como en la revisión del código, que todavía encuentro más fácil de hacer en papel inicialmente.
- ¿Alguna vez ha escrito T-SQL u otros procesos almacenados RDBMS? Usar notación de prefijo en los nombres de las columnas de la base de datos es MUY útil, especialmente para aquellos de nosotros que nos gusta usar editores de texto para este tipo de cosas.
Tal vez, en resumen, el prefijo como una forma de notación es ú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 accesos directos (como el tipado intellisense), pero que no abarca 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: solo una parte de un sistema más grande. No quiero seguir una convención de "automóvil" como permanecer en las carreteras marcadas, cuando a veces, es más rápido simplemente caminar a través de un terreno baldío. Confiar en el IDE para rastrear el tipado variable sería como necesitar que el GPS del automóvil camine a través del lote vacío. Es mejor tener el conocimiento (aunque sea incómodo de tener "m_intCustomerID") en una forma portátil que volver corriendo al automóvil por cada pequeño cambio de rumbo.
Dicho esto, la convención m_o la convención "esto" son legibles. Nos gusta m_ porque se puede buscar fácilmente y aún permite que el tipado variable lo siga. Acordó que un subrayado simple es utilizado por muchas otras actividades de código de marco.
Uso camel case y guiones bajos 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. En las variantes de camel case-method-scope, el guión bajo me recuerda 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.
Yo suelo @.
: D j / k - pero si depende del idioma. Si tiene getters / setters, usualmente pondré un _ en frente de la variable miembro privada y el getter / setter tendrá el mismo nombre sin el _. De lo contrario, generalmente no uso ninguno.
Si el lenguaje admite la palabra clave this o Me , entonces no use prefijo y en su lugar use dicha palabra clave.
Usando C #, he pasado del prefijo ''m _''- a solo un guión bajo , ya que'' m_ ''es un patrimonio de C ++ .
Las Pautas oficiales de Microsoft le dicen que no use ningún prefijo, y que use camel-case en miembros privados y pascal-case en miembros públicos . El problema es que esto colisiona con otra directriz de la misma fuente, que establece que debe hacer que todos los códigos sean compatibles con todos los idiomas utilizados en .NET . Por ejemplo, VB.NET no hace la diferencia entre las cubiertas.
Así que solo un guión bajo para mí. Esto también hace que sea más fácil acceder a través de IntelliSense, y los miembros públicos que llaman solo por código externo no tienen que ver los guiones bajos visualmente desordenados.
Actualización: No creo que el prefijo C # "this." - ayude al "Yo". en VB, que aún verá "Me.age" lo mismo que "Me.Age".
Sin duda, es esencial para entender el código dar a las variables miembro un prefijo para que puedan distinguirse fácilmente de las variables "normales".
Yo disputo este reclamo No es necesario en lo mínimo si tiene un resaltado de sintaxis medio decente. Un buen IDE puede permitirle escribir su código en inglés legible, y puede mostrarle el tipo y el 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 le permitirá usar texto en negrita o cursiva, o cambiar las fuentes por completo. Por ejemplo, me gusta la cursiva para cosas estáticas.
Otra edición: Piénselo de esta manera; el tipo y el alcance de una variable son información secundaria. Debe estar disponible y ser fácil de descubrir, pero no debe gritarle. Si usa prefijos como m_ o tipos como LPCSTR , eso se convierte en ruido, cuando solo desea leer la información principal: la intención del código.
Tercera edición: se aplica independientemente del idioma.
Me gusta m_, pero siempre que se use la convención en el código base, no me molesta.
_ lugar de this.
Yo uso _ también en lugar de this. porque es solo más corto ( 4 caracteres menos) y es un buen indicador de las variables miembro. Además, usando 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;
}
}
Encuentro el primer ejemplo más corto y más claro.
No uso ningún prefijo en absoluto. Si encuentro el peligro de mezclar variables locales o parámetros de método con miembros de la clase, entonces el método o la clase es demasiado largo y se beneficia al dividirse .
Esto (posiblemente) hace que el código sea más legible y algo "fluido", pero lo más importante es que fomenta clases y métodos bien estructurados . Al final, se reduce a un problema completamente diferente del prefijo o no-prefijo dillema.
ACTUALIZACIÓN: bueno, el gusto y las preferencias cambian, ¿no es así? Ahora uso el subrayado como el prefijo para las variables miembro, ya que ha demostrado ser beneficioso para reconocer las variables locales y miembros a largo plazo. Especialmente los nuevos miembros del equipo a veces tienen dificultades cuando los dos no son fácilmente reconocibles.
Subrayar solo.
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 principio de la variable. El "subrayado solo" minimalista lo mantiene legible.
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 te dice rápidamente el alcance básico de cualquier variable; si no hay prefijo, entonces es un local. Además, cuando lee una función, no necesita pensar en lo que se está transmitiendo y qué es simplemente una variable local.