Convención de nomenclatura para params de ctors y setters

Question

Para aquellos de ustedes que le nombran variables miembro sin notación especial como m_foo o foo_, ¿cómo se nombran los parámetros para sus ctors y setters?

Algunas opciones que he probado hasta ahora ...

Obj(int foo) : foo(foo) { } 
void set_foo(int foo) { this->foo = foo; } 

Obj(int _foo) : foo(_foo) { } 
void set_foo(int _foo) { foo = _foo; } 

Obj(int a_foo) : foo(a_foo) { } // a for "argument" 
void set_foo(int a_foo) { foo = a_foo; } 

Obj(int init_foo) : foo(init_foo) { } 
void set_foo(int new_foo) { foo = new_foo; } 

Answer 1

Siempre voy por un sufijo Param o Arg pero sólo cuando es necesario desambiguación.

Obj(int fooArg) : foo(fooArg) 

Answer 2

estoy usando loquesea _, es mejor que _foo ya que no entrará en conflicto con los nombres de funciones específicas de implementación y las palabras clave.

Answer 3

tiendo a seguir la primera letra del parámetro que se está creando, y eliminar la ambigüedad con esto ...

void setFoo(int f) { foo = f; } 

Para un simple organismo, para una variable, es bastante bien clara.

Además, hago a menudo este

int setFoo(const int f) { foo = f; } 

modo de cuerda que puedo cosas juntas.

Answer 4

voy con

Obj(int foo) : mFoo(foo) { } 
void setFoo(int foo) { mFoo = foo; } 

en mis programas. Para constructores de copia y el operador =, tiendo a llamarlo

Obj(Obj const& that):mFoo(that.mFoo) { } 

Para los operadores, voy con

Obj operator+(Obj const& lhs, Obj const& rhs) { ... } 

porque esas son las l EFT h y s ide y el r ight h y s ide de él.

Answer 5

Para las clases:

Obj(int foo) : _foo(foo) {}; 

Para estructuras:

obj_t(int foo_) : foo(foo_) {}; 

Setter:

Obj.setFoo(int foo) { _foo = foo; } 

estoy con litb en el uso de lhs y rhs para las llamadas del operador.

Uso camelCase para las funciones de miembro de clase, y names_with_underscores para campos y métodos de estructura.

Answer 6

Yo solía seguir la convención de Microsoft de prefijación de variables miembro con m_, como m_foo. En mi empresa actual, la convención es un guión bajo final para las variables miembro: foo_.

Generalmente, si trabaja solo, utilice la convención que desee. Si trabajas en equipo, usa lo que decida el equipo. La coherencia general en una base de código es lo importante, no la convención particular.

Answer 7

Evito (por evitar nunca usar) subrayar como el primer carácter de cualquier identificador. Sé que es excesivo pero vale la pena el esfuerzo.

Lea esto: What are the rules about using an underscore in a C++ identifier?

Aunque no es una regla que limite el uso de guión bajo y prefiero caso de camellos para hacer mi variables legible. Pero eso es solo una preferencia personal y no me importa leer el código que lo usa.

Además, nunca nombro los parámetros del mismo modo que las variables de mis miembros. El compilador no lo ayudará a detectar el tipo de errores que esto puede generar (y todo se trata de hacer que el compilador haga el trabajo real para que pueda hacer el trabajo expresivo que el compilador no puede hacer).

int X::setWork(int work) 
{ 
    this->work = work; // OK. But more Java like. 

    work = work;  // Compiler won't see that problem. 
} 

int X::setWork(int newWork) 
{ 
    work = newWork; // A bit harder to get wrong. 
} 

Answer 8

El número dos tiene problemas como convención, aunque en su caso podría ser inofensivo. Un nombre que tiene un guión bajo seguido de un carácter en mayúsculas está reservado para la implementación, y todos los nombres con guiones bajos principales están reservados en un contexto global. Si nunca tienes miembros de clase comenzando con letras mayúsculas (no lo hago), estás a salvo con la convención como se muestra (usando _foo solo como argumento de función), pero no me gusta el nombre de convenciones que faltan cerca de los límites.

Answer 9

siempre hago esto:

Obj(int foo) : foo(foo) {} 

Solía ​​jugar con añadiendo símbolos divertidos hasta que una vez fui golpeado por esto:

Obj(Bar& b) : b_(b_) {} 

Puede usted ver el error? (Sí, b_ es una variable de referencia de miembro privado). Se compiló sin una advertencia. Me costó 3 días de depuración (entonces era un programador ecológico).

Ahora siempre uso el mismo nombre para evitar errores tipográficos (y bloqueos posteriores) como ese. No hay ambigüedad dentro de la lista de inicialización. Esta parte del lenguaje fue diseñada solo para este caso, así que aprovéchala.

Answer 10

que nombrar a los miembros actuales con guiones de fuga, por lo que esto:

Foo(int bar) : bar_(bar) { } 

La razón es para que pueda utilizar las funciones getter y sin nada por el estilo GetBar() (barra() es mejor).

Answer 11

lo hago de esta manera:

obj(int foo) : _foo(foo) { } 
int foo() const { return _foo; } 
void foo(int value) { _foo = value; } 

El único truco aquí es asegurarse de que la letra que sigue al guión es minúscula. Sin embargo, evito el uso de mayúsculas en los nombres de los identificadores en todas partes, ya que es inconsistente con las convenciones utilizadas por la biblioteca estándar (que usa foo_bar_baz para todos los identificadores).

Answer 12

sigo la Google C++ Style Guide

Los nombres de variables son minúsculas, con guiones entre palabras.Las variables de los miembros de la clase tienen guiones bajos posteriores. Por ejemplo: my_exciting_local_variable, my_exciting_member_variable_.