Debo utilizar el mismo nombre para una variable miembro y un parámetro de función en C++

Question

Me pregunto si es una buena práctica usar el mismo nombre para una variable miembro y un parámetro de función en C++. Vengo de un fondo de Java, donde esto era común. Me pregunto si en C++ hay inconvenientes haciendo lo siguiente (el código funciona):

class Player 
{ 
    public: 
    void setState(PlayerState *state) 
    { 
     this->state = state; 
    } 

    private: 
     PlayerState *state; 
} 

Gracias por las respuestas. Según tengo entendido, mientras funciona, una mejor práctica sería poner algún tipo de marcador para diferenciar variable miembro de parámetros de la función como:

_ or m_ 

En algunos editores (como Qt Designer), variables miembro son espectáculos de una manera diferente color. Es por eso que no parece necesario agregar ningún prefijo.

Answer 1

Eso es correcto y permitido por el Estándar. Pero un mejor enfoque es usar alguna convención de nomenclatura para las variables miembro. Por ejemplo, puede usar el prefijo m_ para todas las variables miembro, entonces cualquiera puede inferir qué es m_state. Aumenta la legibilidad del código y evita errores comunes.

Además, si m_state es el miembro, entonces no tiene que escribir this->m_state = state en la función de miembro, puede escribir m_state = state. En su código actual, se hace necesaria la parte this->, sin la cual state = state se convertirá en autoasignación.

Answer 2

Le sugiero que siga alguna convención de estilo de codificación. Personalmente utilizo el:

class Player 
{ 
    public: 
    void setState(PlayerState *state) 
    { 
     _state = state; 
    } 

    private: 
     PlayerState* _state; 
} 

Answer 3

Normalmente, las personas solo colocan un guión bajo después de la variable o usan nombres de var menos descriptivos más cortos para el parámetro de la función.

Personalmente, no me gusta el nombre del mismo nombre porque al leerlo, es fácil cometer errores.

Answer 4

Está bien, de hecho, incluso podría ser una buena forma, siempre y cuando sea solo en su constructor.

Answer 5

No existe realmente ninguna diferencia entre C++ y Java, el único inconveniente es que debe escribir this-> state = state en lugar de state = arg. Pero su código es perfectamente aceptable, es más estilo que cualquier otra cosa.

Answer 6

hacerlo de esta manera:

class Player 
{ 
    public: 
    void setState(PlayerState *state) 
    { 
     this->m_state = state; 
    } 

    private: 
     PlayerState *m_state; 
} 

Me lo agradecerás algún tiempo más tarde. Jaja .. (:

El "m_" ("Miembro") prefijo de distinguir a los miembros de funciones y otras cosas muy útiles con cosas como IntelliSense (o cualquier otro IDE autosugestión)

Asimismo, la marca.. .. m_state como const si usted no tiene intención de cambiar más adelante si acaso

Answer 7

Esto es más una cuestión de estilo que cualquier otra cosa mayoría de las veces, no hay problema:. state es un nombre muy pobre para una variable o un valor, como variables y valores deben ser nombres calificados, por ejemplo:

void setState(PlayerState* newState) 
{ 
    currentState = newState; 
} 

En teoría, de todos modos.En la práctica, he encontrado que es útil el uso de prefijos, lo largo de las líneas de:

class Player 
{ 
    PlayerState* myState; 
public: 
    void setState(PlayerState* newState) 
    { 
     myState = newState; 
    } 
}; 

Al leer el código, si el nombre comienza con my, está claro que es una variable miembro (y si se comienza con our, es un miembro estático variable).

Nota también que en el constructor, puede hacer cosas como:

Player::Player(PlayerState* state) 
    : state(state) 
{ 
} 

sin embargo no estoy seguro de lo que esto hace para facilitar la lectura,:

Player::Player(PlayerState* initialState) 
    : myState(initialState) 
{ 
} 

parece mucho más claro (pero para titulares de datos simples, la distinción podría ser no tan significativa).

Answer 8

Me parece una buena opción dar a las variables miembro el mismo nombre que los parámetros de inicialización del constructor. Aquí están mis razones:

• reduce el número de identificadores = reduce la complejidad
• no es necesario inventar tantos identificadores
• mismas cosas deben tener el mismo nombre, si es posible, es decir lógicamente hablando , Sé el parámetro! = Miembro.
  • contextos e índices pueden permitir dar el mismo nombre a la misma cosa
• a encontrar más fácilmente referencias (identificadores) a lo lógico mediante la búsqueda, si todas las referencias tienen el mismo nombre

Answer 9

Tenga en cuenta que algunos compiladores (vs 2015) pueden generar una advertencia si una variable sombrea a otra. Por supuesto, uno puede desactivar este tipo de advertencias. Pero creo que es una buena práctica tener estas verificaciones habilitadas.