PMD - Code Analyzer Warnungen

Question

Ich verwende PMD, um Code zu analysieren, und es erzeugt einige Warnungen mit hoher Priorität, die ich nicht zu beheben weiß.

1) Avoid if(x!=y)..; else...; Aber was soll ich tun, wenn ich diese Logik brauche? Das heißt, ich muss überprüfen, ob x!=y? Wie kann ich es umgestalten?

2) Use explicit scoping instead of the default package private level. Aber die Klasse wird tatsächlich nur innerhalb des Pakets verwendet. Welchen Zugriffsmodifizierer soll ich verwenden?

3) Parameter is not assigned and could be declared final. Sollte ich das endgültige Schlüsselwort zu allen Orten hinzufügen, auf die PMD mit dieser Warnung hingewiesen hat?

Answer 1

Vermeiden Sie die Negation: Anstelle von , überprüfen Sie zuerst den positiven Fall, weil Menschen/Menschen dazu neigen, positive Dinge mehr als negativ zu mögen. Es bringt das Gehirn dazu, beim Lesen des Quellcodes die Logik umzukehren.Anstatt also schreiben:

if (x!=y) doThis() else doThat()  // Bad - negation first 
if (x==y) doThat() else doThis()  // Good - positive first 

Explicit Scoping: Nach PMD website, es ist eine umstrittene Regel. Du magst es hassen, jemand anderes mag es. Was Sie tun sollten, ist alle Felder in Ihren Klassen privat zu machen. Es scheint ein Feld oder eine Methode (keine Klasse) mit einer Paketsichtbarkeit, z.B. so etwas wie dieses:

class Foo { 
    /* private missing */ Object bar; 
} 

Schluss Parameter: Methodenparameter sollte ein versehentliches Neuzuordnung zu vermeiden, ist endgültig. Das ist nur eine gute Übung. Wenn Sie Eclipse verwenden, bietet der Inhaltshilfsdienst sogar einen Quickfix mit der Bezeichnung "Ändern Sie Modifikatoren zum endgültigen, wo möglich". Wählen Sie einfach den gesamten Code im Editor mit Strg-a und drücken Sie dann Strg-1.

Answer 2

Alle diese scheinen wie kleine Warnungen, die ausgeschaltet werden könnten.

1) Es will Sie die Logik

if(x==y) { 
    //old else clause 
} else { 
    //old if clause 
} 

2) kippen Wenn Paket wirklich der richtige Zugang ist, dass Sie möchten, gibt es keinen Zugriffsmodifikator hinzuzufügen. Ich bin nicht vertraut genug, um zu wissen, ob es einen Weg gibt, diese spezielle Warnung zu unterdrücken.

3) Ein Stilproblem. Manche Leute wollen endgültig auf alles, was sie haben könnte. Andere denken, es fügt zu wenig Information zu viel Krempel hinzu. Wenn du im zweiten Lager bist, schalte diese Warnung ab.

Answer 3

In Bezug auf den ersten Punkt (die Ungleichheit) gibt es zwei Probleme:

1) Ablesbarkeit der doppelten Negation.

Angenommen, Sie haben:

if(x!=y) { false clause } else { true clause } 

Die zweite Klausel wird ausgeführt, wenn "nicht x nicht gleich y ist".

if (x==y) {true clause } else {false clause}. 

2) Korrektheit::

Dies kann wie folgt umgeschrieben werden, wenn X und Y nicht-Primitive ist, unter Verwendung von if(!x.equals(y)) sicherer ist. Dies entspricht der Verwendung von == anstelle von .equals() und kann zu sehr schwerwiegenden Fehlern führen.

Answer 4

Sie müssen nicht alle Regeln aktivieren. Wählen Sie einige der Regeln, denen Sie zustimmen, und korrigieren Sie Ihren Code, bis alle Warnungen gelöscht sind.

- Refactor es auf eine if (x == y) ... else ... Logik. Vermeiden Sie einfach negative Bedingungen in if Statements, sie machen Code schwieriger zu verstehen

- Ich würde diese Regel nicht aktivieren.

- Viele Leute deklarieren viele Felder und Variablen endgültig. Vor allem, wenn sie sicherstellen oder ausdrücken wollen, dass der Wert einer Variablen in der Methode nicht geändert werden soll. Wenn Ihnen das nicht gefällt, deaktivieren Sie diese Regel.

Answer 5

Sie können // NOPMD auch am Ende jeder Zeile verwenden, in der PMD-Regeln nicht überprüft werden sollen.

Zum Beispiel für den oben angegebenen Code, den Sie, indem PMD-Check unterdrücken können,

class Foo { 
    /* private missing */ Object bar; // NOPMD 
} 

Bitte beachten Sie, dass der obige Kommentar leise andere Warnungen in der gleichen Linie unterdrücken kann.