I nomi delle variabili possono corrispondere ai nomi dei campi? [chiuso]

Qui fai molte domande diverse.

Can variable names match field names?

Dipende dalla lingua. In alcuni, possono. In alcuni, ma l'uno può oscurare l'altro. In alcuni, non possono.

Generally speaking, which one is prefered?

Dipende dalla lingua. O, più precisamente, sugli standard di codifica di ogni particolare organizzazione, che sarà, tuttavia, spesso ispirata dallo standard di codifica della comunità della lingua (se ne esiste uno).

Does it depends on language (Java, C++, C#, etc.)?

Sì.

In Ruby, ad esempio, è possibile che getter e setter assomiglino a questo, e alcune persone preferiscono questo stile:

class Foo
  def bar
    @bar
  end

  def bar=(bar)
    @bar = bar
  end
end

I, e alcuni altri preferiscono questo stile:

class Foo
  def bar
    @bar
  end

  def bar=(val)
    @bar = val
  end
end

Si noti, tuttavia, che questa domanda si presenterà molto meno spesso di quanto si pensi, perché ogni programmatore Ruby che si rispetti non scriverebbe un codice così ripetitivo a mano ma invece lo sintetizza:

class Class
  def generate_getter(*names)
    names.each do |name|
      define_method(name) do
        instance_variable_get(:"@#{name}")
      end
    end
  end

  def generate_setter(*names)
    names.each do |name|
      define_method(:"#{name}=") do |val|
        instance_variable_set(:"@#{name}", val)
      end
    end
  end

  def generate_getter_and_setter(*names)
    generate_getter(*names)
    generate_setter(*names)
  end
end

class Foo
  generate_getter_and_setter :bar
end

In realtà, questo modello è così comune, che questi metodi vengono effettivamente spediti come parte della libreria principale sotto i nomi di Module#attr_reader , Module#attr_writer e Module#attr_accessor :

class Foo
  attr_accessor :bar
end

In Java, OTOH, sembra essere molto comune scrivere in realtà ogni getter e setter per intero, non importa quanto banale, e non generarli o sintetizzarli. Quindi, la domanda si presenta molto più spesso, e quindi è molto più probabile che ci saranno standard di codifica che la governano. In particolare, se la maggior parte dei tuoi getter e setter sono insignificanti, allora il potenziale di confusione è piuttosto basso (in che modo puoi confonderti in un metodo che è solo una singola linea banale?), E quindi, è più accettabile usare il stesso nome per il parametro del setter e il campo di supporto:

void setBar(X bar) { this.bar = bar; }

Questo è un pattern che è facilmente riconoscibile, e dal momento che ci sono così tanti setter insignificanti, i programmatori sono addestrati per questo modello, e quindi possono individuarlo anche in setter più grandi, più complessi e non banali.

OTOH, in C #, i getter e i setter banali vengono solitamente generati automaticamente, quindi gli unici in cui la scelta del nome del parametro è importante non sono banali, e quindi il potenziale di confusione è maggiore, e i programmatori non lo sono usato così tanto:

X Bar { get; set; } // auto-generated, trivial, programmer doesn't care

E nel caso di un setter non banale, la lingua effettivamente prescrive il nome del parametro (o, più precisamente, non c'è parametro , piuttosto, c'è una parola chiave speciale value , che valuta il valore passato al setter), quindi l'unica scelta è su come denominare il campo di supporto. Per questo, non ci sono linee guida, dal momento che gli standard di codifica si applicano solo al codice pubblicamente visibile (cioè public e protected membri) ei campi di supporto dovrebbero essere private (altrimenti, perché hanno getter e setter?). Tuttavia, poiché i campi dovrebbero essere denominati camelCase e le proprietà dovrebbero essere denominate PascalCase , non possono esserci conflitti tra di esse. (Questo è diverso in un linguaggio insensibile alle maiuscole e minuscole come VB.NET, ad esempio!)

private X bar;

X Bar
{
    get { return bar; }
    set { bar = value; }
}

o

private X _bar;

X Bar
{
    get { return _bar; }
    set { _bar = value; }
}

Questi due sembrano essere gli stili predominanti nella comunità .NET. Entrambi in realtà violano alcuni standard di denominazione ( Non nominare identificatori solo nel caso e Non utilizzare caratteri di sottolineatura ), ma tali standard si applicano solo agli identificatori pubblici, che il campo base non lo è. Poiché ampie parti di .NET sono ora open source, è effettivamente possibile vedere quali standard di denominazione Microsoft usa internamente e sembrano preferire il secondo (prefisso di sottolineatura). Ecco un esempio dalle .NET Concurrent Collections, che sono un'aggiunta piuttosto nuova a .NET e quindi dovrebbero riflettere gli standard di codifica abbastanza recenti :

private int _boundedCapacity;

public int BoundedCapacity
{
    get
    {
        CheckDisposed();
        return _boundedCapacity;
    }
}

La maggior parte se non tutte le lingue lo consentono.

È considerato una cattiva pratica perché rende confuso il codice - perché denominare due cose che sono diverse le stesse?

Ad esempio se si dispone di una classe di radiatore con un campo denominato temperatura e si desidera un metodo che controlli se la temperatura del radiatore è superiore alla temperatura ambiente corrente, che si passa, è meglio avere isWarmer (roomTemperature) che isWarmer (temperatura) perché non vuoi che temperatura e temperatura si riferiscano a due cose diverse quando sono entrambe rilevanti per il comportamento del metodo.

Con i costruttori oi metodi setter ha senso chiamarli allo stesso modo perché l'unico punto del metodo è assegnare un parametro a un campo della classe.

I compilatori standard * per C ++, Java e C # consentono di nascondere un campo con un parametro o una variabile. In tutte e tre le lingue, la parola chiave this oi modificatori di classe (in caso di campi statici) possono consentire l'accesso ai campi nascosti. Quindi sì, è possibile che tu abbia lo stesso nome per campi e variabili / parametri in queste lingue almeno in queste tre lingue.