È una cattiva pratica usare lo stesso nome per argomenti e membri? [chiuso]

Question

È una cattiva pratica usare lo stesso nome per argomenti e membri? [chiuso]

#1 da (12 voti)
#2 da (7 voti)
#3 da (2 voti)
#4 da (1 voti)

3

A volte scrivo codice costruttore come

class X
{
public:
  X( const int numberOfThingsToDo ) :
    numberOfThingsToDo( numberOfThingsToDo )
  {
  }

private:
  int numberOfThingsToDo;
};

o in C #

class X
{
  public X( int numberOfThingsToDo )
  {
     this.numberOfThingsToDo = numberOfThingsToDo;
  }

  private int numberOfThingsToDo;
}

Penso che la ragione principale sia che quando trovo un nome membro appropriato, non vedo alcun motivo per usarne uno diverso per l'argomento inizializzandolo, e visto che non sono nemmeno un fan dell'uso dei caratteri di sottolineatura, il più semplice è solo prendere lo stesso nome Dopotutto è adatto. È considerata una cattiva pratica? Qualche inconveniente (a parte spararti nel piede quando dimentichi il this in C #)?

naming

posta stijn 08.10.2012 - 15:51

fonte

4 risposte

7

Questo è forse uno di quei tipi di problemi che riguardano la religione. Alcuni pensano che lo shadowing, almeno nei costruttori e nei setter, sia esattamente la cosa giusta da fare. L'ho persino visto promosso come una pratica "dovrebbe" (ma non un "deve") in un paio di standard di codifica. Altri pensano che sia assolutamente orrendo. Alcuni standard di codifica designano questo come una pratica "non". Personalmente non mi piace la pratica, ma la mia antipatia personale non è abbastanza strong che mi sento in dovere di scriverlo negli standard che scrivo o aiuto a scrivere. "Non combattere le piccole cose" e "non iniziare a programmare le guerre di religione" avere la precedenza sui miei sentimenti personali in questo senso.

Come nota a margine, il compilatore C ++ di GNU, insieme ad altri, fornisce un'opzione -Wshadow o equivalente che avverte sui nomi dei parametri che ombreggiano i nomi dei membri dei dati. Nota: questa opzione non è una di quelle abilitate da -Wall . Apparentemente gli autori del compilatore GNU non vogliono nemmeno iniziare una guerra religiosa.

Esiste una terza opzione con C ++: utilizzare lo shadowing laddove appropriato nelle dichiarazioni di costruttori e setter, ma utilizzare nomi diversi nelle definizioni di tali funzioni membro. Per quanto riguarda il compilatore, non c'è niente di sbagliato nel dare un parametro diverso nella dichiarazione (prototipo) di una funzione e nella definizione della funzione. Non mi piace particolarmente questa pratica, ma l'ho vista usata intenzionalmente, non solo accidentalmente.

risposta data 08.10.2012 - 16:57

fonte

2

Non solo non è male, a mio parere, personalmente lo preferisco. Se la lingua supporta la differenziazione della variabile membro dalla variabile locale, nominali entrambi e usa quell'opzione (come this nel tuo caso).

Per me è molto più facile capirlo,

void setVariable(int varName) { this.varName = varName);

piuttosto che capire come impostare la variabile membro su una variabile locale con un nome completamente diverso.

Come ha detto Kevin, se la lingua, o la tua azienda, ha una "migliore pratica" per questo già in uso, usala per evitare confusione. Altrimenti, penso che tu sia al sicuro usando lo stesso nome. La maggior parte degli IDE che valgono il loro peso renderanno la distinzione ovvia.

risposta data 08.10.2012 - 17:48

fonte

1

Ho usato lo stesso nome per molto tempo e l'unico esempio veramente problematico che ho trovato è il seguente in c ++:

class A { A(int a_) : a(a) { } int a; }; // error, a uninitialized afterwards.

Altrimenti sembra funzionare sempre. Alcuni conflitti di nome minori possono accadere e rinominare il membro in m_a di solito lo risolve; ma la variabile non inizializzata nel Ctor init è l'aspetto più problematico.

risposta data 08.10.2012 - 17:59

fonte

Leggi altre domande sui tag naming

Codice Morse - Albero binario Utilizzo di ref anziché out. Sarebbe considerato un bug?

score 12 · Accepted Answer

Non ha molta importanza. Se esiste una pratica universalmente accettata per la lingua, seguila. In caso contrario, quindi seguire qualsiasi pratica è il consenso per la tua squadra. Se lavori da solo, allora fai come ti pare.

Distinguere tra variabili locali e membri dei dati non dovrebbe essere un problema. Se hai così tante variabili in ambito che è un problema, la tua classe è troppo grande.