Se i RequireThis il check-in Checkstyle essere abilitato?

Question

Una delle built-in controlli Checkstyle è RequireThis , che si spegne ogni volta non si antepone this. al campo o chiamate di metodi locali. Ad esempio,

public final class ExampleClass {
    public String getMeSomething() { 
        return "Something"; 
    }

    public String getMeSomethingElse() {
        //will violate Checkstyle; should be this.getMeSomething()
        return getMeSomething() + " else"; 
    }
}

Sto lottando con se questo controllo è giustificato. Nell'esempio di cui sopra, la ExampleClass è definitiva, che dovrebbe garanzia che la versione "diritto" di getMeSomething dovrebbe essere invocato. Inoltre, sembra che ci siano casi in cui si potrebbe desiderare sottoclassi di ignorare il comportamento predefinito, nel qual caso richiedendo "questo" è un comportamento sbagliato.

Infine, sembra che il comportamento di codifica eccessivamente difensivo che solo ingombra la fonte e rende più difficile per vedere che cosa è effettivamente in corso.

Quindi, prima di suggerire al mio architetto che questa è una cattiva controllo per attivare, mi chiedo se chiunque altro ha permesso a questo controllo ? Avete preso un bug critico a seguito di un this mancante?

Answer 1

Il RequireThis regola non ha un impiego valido che possa prevenire una possibile bug nei metodi e costruttori quando si applica ai campi. Il codice che segue è quasi certamente un bug:

void setSomething(String something) {
    something = something;
}

Un codice come questo compilerà, ma non farà nulla, tranne riassegnare il valore del parametro del metodo a se stesso. E 'più probabile che l'autore intendeva fare questo:

void setSomething(String something) {
    this.something = something;
}

Questo è un errore di battitura che potrebbe accadere e vale la pena di controllare per quanto può aiutare a prevenire problemi difficili da eseguire il debug se il codice non è riuscito perché this.something non è impostato molto più tardi nel programma.

Le impostazioni Checkstyle consentono di mantenere questo controllo utile per i campi omettendo il controllo di gran parte inutili per i metodi configurando la regola in questo modo:

   <module name="RequireThis">
       <property name="checkMethods" value="false"/>
   </module>

Quando si tratta di metodi di questa regola non ha alcun effetto reale perché chiamando this.getMeSomething() o semplicemente getMeSomething() ha alcun effetto sulla risoluzione dei metodi di Java. Chiamando this.getSomethingStatic() funziona ancora quando il metodo è statico questo non è un errore, è solo un avvertimento in diversi IDE e strumenti di analisi statica.

Answer 2

avrei sicuramente spegnerlo. Utilizzando this.foo() non è idiomatica Java, e deve quindi essere usato solo quando è necessario, per segnalare che qualcosa di speciale sta succedendo nel codice. Ad esempio, in un setter:

void setFoo(int foo) {this.foo = foo;}

Quando ho letto il codice che fa uso gratuito di questo, io in genere segnarlo fino a un programmatore, senza una solida conoscenza sulla programmazione orientata agli oggetti. In gran parte perché ho generalmente visto che lo stile di codice da programmatori che non capiscono che questo non richiesto in tutto il mondo.

Sono francamente sorpreso di vedere questo come una regola nella biblioteca di CheckStyle.

Answer 3

La chiamata con "questo". non si ferma l'invocazione di chiamare un metodo override in una sottoclasse, dal momento che questo si riferisce a "questo oggetto" non "questa classe". Esso dovrebbe impedirvi di confondere un metodo statico per un metodo di istanza però.

Per essere onesti, che non suona come un problema particolarmente comune, io personalmente non penserei che vale il trade-off.

Answer 4

Personalmente non abilitarlo. Soprattutto perché ogni volta che ho letto il codice ho letto in un IDE (o qualcos'altro che fa formattazione del codice intelligente). Ciò significa che i diversi tipi di chiamate di metodo e di accessi di campo sono formattati in base al loro reale significato semantico e non sulla base di alcune indicazioni (forse sbagliato).

this. non è necessario per il compilatore e quando l'IDE fa formattazione intelligente, allora non è necessario che l'utente sia. E la scrittura di codice non necessario è solo una fonte di errori in questo codice (in questo esempio: utilizzando this. in alcuni luoghi e non lo si utilizza in altri luoghi).

Answer 5

Vorrei attivare questo controllo solo per i campi, perché mi piace l'informazioni extra aggiunto da 'this.' di fronte a un campo.
Vedere la mia (vecchia) domanda: Ti prefisso l'istanza variabile con 'questo' in java? .

Ma per qualsiasi altro progetto, specialmente quelli legacy, non vorrei attivarlo:

• le probabilità sono, la parola 'this.' è quasi non utilizzato, il che significa questo controllo avrebbe generato tonnellate di avvertimenti.
• override di denominazione (come un campo e un metodo con un nome simile) sono molto rari a causa della corrente IDE segnalazione di default che il codice con un avvertimento di loro.