c++ - programación - reglas para nombrar variables en programacion

Convención de nombres 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

Tiendo a seguir la primera letra del parámetro que se está estableciendo, y desambiguo con esto ...

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

Para un setter simple, para una variable, está bastante claro.

Además, a menudo hago esto

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

entonces puedo unir cosas.

Answer 2

Estoy usando foo_, es mejor que _foo ya que no entrará en conflicto con nombres de funciones y palabras clave específicos de la implementación.

Answer 3

Siempre busco un sufijo Param o Arg pero solo cuando es necesaria la desambiguación.

Obj(int fooArg) : foo(fooArg)

Answer 4

Solía ​​seguir la convención de Microsoft de prefijar 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_ .

En general, 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 5

Voy con

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

en mis programas Para los constructores de copia y 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 esos son el l eft h y s ide y el r derecho h y s ide de él.

Answer 6

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 me desagradan las convenciones de nombres que faltan cerca de los límites.

Answer 7

Para clases:

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

Para las estructuras:

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

Setter:

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

Estoy preocupado por el uso de lhs y rhs para las llamadas de los operadores.

Uso camelCase para las funciones de miembros de la clase y names_with_underscores para los campos y métodos de la estructura.

Answer 8

Yo siempre hago esto:

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

Solía ​​jugar juegos con símbolos graciosos añadidos hasta que una vez fui golpeado por esto:

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

¿Puedes 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 subsecuentes) 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 9

Lo hago así:

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 bajo esté en minúscula. Sin embargo, evito 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 10

Sigo la Guía de estilo de Google C ++

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

Answer 11

Yo nombro a los miembros reales con guiones bajos, así que hago esto:

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

La razón es para que pueda usar las funciones getter sin nada como getBar () (bar () es mejor).

Answer 12

Evito (por evitar mean mean never use) subrayar como el primer caracter de cualquier identificador. Sé que es excesivo pero vale la pena el esfuerzo.

Lea esto: ¿Cuáles son las reglas sobre el uso de un guión bajo en un identificador de C ++?

Aunque no es una regla, limito el uso del guión bajo y prefiero el camello para que mis variables sean legibles. 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 de la misma manera que mis variables miembro. 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.
}