Qual è lo stile accettato per l'utilizzo della parola chiave 'this' in Java?

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

È davvero ridondante.

Preferisco usare this . Semplifica la lettura del codice in vari editor che colorano le variabili locali e di istanza nello stesso modo. Rende anche più facile leggere il codice su una pagina stampata durante qualcosa come una revisione del codice. È anche un promemoria abbastanza strong per quanto riguarda l'ambito della variabile per altri sviluppatori.

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

Credo che L'ultima frase di ChrisF è morta: sii coerente con il tuo utilizzo.

Un posto in cui uso costantemente "questo" è setter e / o costruttori:

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

Oltre a ciò, non ritengo sia necessario aggiungerlo. Durante la lettura del corpo di un metodo, i parametri e le persone del posto sono proprio lì - e abbastanza facili da tenere traccia di (anche senza l'aiuto dell'IDE). Anche i locali e i campi tendono ad essere di diversa natura (stato dell'oggetto vs memoria transitoria o parametro).

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 "this" per taggare i campi, ti consiglio di assicurarti che la convenzione sia sempre seguita rigorosamente - sarebbe davvero facile iniziare a pensare che no "questo" significa che è un locale e distruggere la roba basata sul ipotesi.

modifica: anch'io finisco per usarlo in equals, 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 a aggiungere this , ma ReSharper ha una regola predefinita che dice che this è ridondante (che è) 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 le regole significano è che tu sei coerente nel tuo utilizzo - che è probabilmente la cosa più importante.

Is it considered a bad practice to always prepend this to the current instance attributes?

Sì - da alcuni, no - da altri.

Mi piace e utilizzo la parola chiave this nei miei progetti in Java e C #. Si può sostenere che IDE evidenzierà sempre parametri e campi di diverso colore, ma non sempre funzioniamo in IDE - dobbiamo fare un sacco di fusioni / differenze / alcune modifiche rapide in un blocco note / controllare alcuni frammenti di codice nell'e-mail . È modo più facile per me individuare dal primo sguardo in cui lo stato dell'istanza è cambiato, ad esempio per esaminare alcuni possibili problemi di concorrenza.

Penso che se hai bisogno di usarlo, hai un metodo troppo lungo, o una classe che sta cercando di fare troppo o entrambi.

I metodi non dovrebbero mai essere più di poche righe di codice, usare una o due variabili locali, determinare cosa è ciò che diventa facile; anche con il solo contesto delle 3 linee 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 è dividerle.

Penso che "questo" sia solo un codice di clutter. Soprattutto con IDE moderni che colorano i parametri locali / variabili locali / campi in modo diverso.

Penso che tu abbia risposto alla tua stessa domanda con questo:

It feels more natural to me to write

... this.foo ...

than

... foo ...

as it helps me to distinguish instance attributes from local variables.

Se ti senti più a tuo agio con this. mentre migliora le tue conoscenze lavorative con Java, allora usa assolutamente la cosa ( Penso che sia, in un certo senso, il familiare SelfPython di cui si sta parlando ).

Il fatto è che, sebbene le persone forniscano argomenti solidi / pertinenti sull'uso o meno di this. , sembra ancora un dibattito, un esempio dato:

• rende chiaro lo scopo delle variabili vs. , dovresti riscrivere il codice se non è chiaro quale sia ogni variabile;
• this. è ridondante se trascorri l'intera giornata nell'IDE vs. eseguo revisioni di codice e faccio diff su diverse versioni utilizzando un comparatore senza evidenziazione della sintassi;
• non digitare this. mi guadagna importanti millisecondi di produttività vs. vengo pagato premendo il tasto e aggiungendo this. è come un aumento di retribuzione: D;
• ecc. ecc.

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

Normalmente l'aggiunta di questo non è necessaria. 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 utile in un paio di situazioni specifiche:

Sovrascrittura dei parametri locali - a volte è necessario specificare che si desidera utilizzare una variabile di istanza piuttosto che un parametro / variabile locale con lo stesso nome. Questo è abbastanza comune nei costruttori, in cui si desidera che il nome del parametro corrisponda al nome interno della variabile di istanza utilizzata per inizializzare, ad es.

class MyObject {
  int value;

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

Quando gestisci altre istanze della stessa classe - credo che renda il codice più chiaro e comprensibile per essere esplicito su quale istanza della classe ti stai riferendo, ad es.

class MyObject {
  int value;
  ....

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