Qual è lo stile accettato per usare la parola chiave `this` in Java?

Vengo da linguaggi come Python o Javascript (e altri meno orientati agli oggetti) e sto cercando di migliorare la mia conoscenza operativa di Java, che conosco solo in modo superficiale.

È considerata una cattiva pratica anteporre sempre thisagli attributi dell'istanza corrente? Mi sembra più naturale scrivere

...
private String foo;

public void printFoo() {
    System.out.println(this.foo);
}
...

di

...
private String foo;

public void printFoo() {
    System.out.println(foo);
}
...

poiché mi aiuta a distinguere gli attributi di istanza dalle variabili locali.

Ovviamente in un linguaggio come Javascript ha più senso usare sempre this, poiché si può avere più annidamenti di funzioni, quindi variabili locali provenienti da ambiti più ampi. In Java, per quanto ho capito, non è possibile nidificare in questo modo (tranne che per le classi interne), quindi probabilmente non è un grosso problema.

In ogni caso, preferirei usare this. Sarebbe strano e non idiomatico?

Nella maggior parte degli IDE, puoi semplicemente passare il mouse sopra la variabile se vuoi sapere. Inoltre, davvero, se stai lavorando con un metodo di istanza, dovresti davvero conoscere tutte le variabili coinvolte. Se ne hai troppi o i loro nomi si scontrano, allora devi fare il refactoring.

È davvero abbastanza ridondante.

Preferisco usare this. Semplifica la lettura del codice in vari editor che colorano le variabili locali e di istanza allo stesso modo. Inoltre, semplifica la lettura del codice su una pagina stampata durante una revisione del codice. È anche un promemoria abbastanza forte per quanto riguarda l'ambito della variabile per altri sviluppatori.

Tuttavia, ci sono argomenti contro questo. Nei moderni IDE, puoi scoprire l'ambito di una variabile passando con il mouse sopra di essa o visualizzandola in una struttura ad albero. Puoi anche cambiare il colore e / o la faccia del carattere delle variabili a seconda del loro ambito (anche in modo tale che, una volta stampato, sia evidente quale sia lo scopo della variabile).

Credo che l'ultima frase di ChrisF sia morta: sii coerente nel tuo utilizzo.

Un posto che uso costantemente "questo" è setter eo costruttori:

public void setFoo(String foo) {
    this.foo = foo;
}

A parte questo, non credo sia necessario aggiungerlo. Quando si legge il corpo di un metodo, i parametri e i locali sono proprio lì - e abbastanza facili da tenere traccia (anche senza l'aiuto dell'IDE). Anche i locali e i campi tendono ad essere di natura diversa (stato dell'oggetto o memoria o parametro transitorio).

Se c'è confusione su cosa sia una variabile e cosa sia un campo, probabilmente significa che un metodo ha troppe variabili / parametri, è troppo lungo e troppo complesso e dovrebbe essere semplificato.

Se scegli di usare 'questo' per taggare i campi, ti consiglio di assicurarti che la convenzione sia sempre seguita rigorosamente - sarebbe davvero facile iniziare a dare per scontato che non 'questo' significhi che è un locale e rompere le cose in base al presupposto.

modifica: finisco anche per usarlo in uguale a, clone o qualsiasi cosa che abbia un parametro 'that' dello stesso tipo di oggetto:

public boolean isSame(MyClass that) {
    return this.uuid().equals(that.uuid());
}

È discutibile.

Prendendo C # come un'analogia in quanto ha una sintassi e una struttura molto simili a Java, troviamo che C # StyleCop ha una regola predefinita che insiste sull'aggiunta this, ma ReSharper ha una regola predefinita che dice che thisè ridondante (quale è) e può essere rimosso.

Quindi se stai usando uno strumento, li aggiungerai, ma se ne usi un altro, li rimuoverai. Se stai utilizzando entrambi gli strumenti, dovrai scegliere e disabilitare una delle regole.

Tuttavia, ciò che significano le regole è che sei coerente nel tuo utilizzo - che è probabilmente la cosa più importante.

È considerato una cattiva pratica anteporre sempre questo agli attributi dell'istanza corrente?

Sì - da alcuni, no - da altri.

Mi piace e utilizzo la thisparola chiave nei miei progetti in Java e C #. Si può sostenere che IDE metterà sempre in evidenza parametri e campi di colore diverso, tuttavia non sempre si lavora in IDE - dobbiamo fare molte fusioni / differenze / alcune modifiche rapide in un blocco note / controllare alcuni frammenti di codice nell'e-mail . È molto più facile per me individuare fin dalla prima occhiata in cui viene modificato lo stato dell'istanza, ad esempio esaminare alcuni possibili problemi di concorrenza.

Penso che se hai bisogno di usare questo, hai un metodo troppo lungo, o una classe che sta provando a fare troppo, o entrambi.

I metodi non dovrebbero mai essere più lunghi di poche righe di codice, usare una o due variabili locali, determinando cosa diventa facile; anche con solo il contesto a 3 righe della maggior parte degli strumenti diff. Se i tuoi metodi sono troppo lunghi e le tue classi hanno troppe responsabilità (spesso significano troppi campi), la soluzione è invece dividerle.

Penso che "questo" ingombra solo il codice. Soprattutto con gli IDE moderni che colorano i parametri locali / variabili / campi locali in modo diverso.

Penso che tu abbia risposto alla tua domanda con questo:

Mi sembra più naturale scrivere

... this.foo ...

di

... foo ...

poiché mi aiuta a distinguere gli attributi di istanza dalle variabili locali.

Se ti senti più a tuo agio nell'utilizzare this.migliorando le tue conoscenze lavorative con Java, allora usa sicuramente la cosa ( penso che sia, in un certo senso, il familiare sé Python a cui ti stai relazionando ).

Il fatto è che, sebbene le persone forniranno argomenti solidi / pertinenti sull'uso o non sull'uso this., sembra comunque un dibattito, ad esempio:

• rende chiaro lo scopo delle variabili vs. dovresti riscrivere il codice se non è chiaro quale sia ciascuna variabile;
• this.è ridondante se trascorri l'intera giornata nell'IDE rispetto a quando eseguo revisioni del codice e fai diff su diverse versioni utilizzando un comparatore senza evidenziazione della sintassi;
• non digitare this.mi guadagna importanti millisecondi di produttività rispetto a quando vengo pagato con il tasto premuto e l'aggiunta this.è come un aumento di stipendio: D;
• ecc ecc

Ma la linea di fondo è che alla fine della giornata riprende ancora con le preferenze personali e l'ambiente di lavoro .

Normalmente aggiungere questo non è necessario. Non penso che sia una cattiva pratica di per sé, ma un uso eccessivo di questo sarebbe probabilmente considerato insolito nella maggior parte delle basi di codice Java che ho visto.

Tuttavia lo trovo prezioso in un paio di situazioni specifiche:

Sostituzione dei parametri locali : a volte è necessario specificare che si desidera utilizzare una variabile di istanza anziché un parametro / variabile locale con lo stesso nome. Questo è abbastanza comune nei costruttori, dove si desidera che il nome del parametro corrisponda al nome interno della variabile di istanza che viene utilizzato per inizializzare, ad es.

class MyObject {
  int value;

  public MyObject(int value) {
    this.value=value;
  }
}

Quando gestiamo altre istanze della stessa classe , credo che renda il codice più chiaro e comprensibile per essere esplicito a quale istanza della classe a cui ti riferisci, ad es.

class MyObject {
  int value;
  ....

  public MyObject add(MyObject other) {
    return new MyObject( this.value + other.value )
  }
}