PMD - ostrzeżenia analizatora kodu

Question

Używam PMD do analizy kodu i generuje on kilka ostrzeżeń o wysokim priorytecie, których nie potrafię naprawić.

1) Avoid if(x!=y)..; else...; Ale co powinienem zrobić, jeśli potrzebuję tej logiki? Oznacza to, że muszę sprawdzić, czy x!=y? Jak mogę to zmienić?

2) Use explicit scoping instead of the default package private level. Ale klasa jest rzeczywiście używana tylko w pakiecie. Jakiego modyfikatora dostępu powinienem użyć?

3) Parameter is not assigned and could be declared final. Czy należy dodać słowo kluczowe do wszystkich miejsc, które PMD wskazał z tym ostrzeżeniem?

Answer 1

Unikać negacja: Zamiast if(x!=y) doThis() else doThat(), sprawdź pozytywnego przypadku pierwsze, dlatego, że ludzie/ludzie mają tendencję do jak pozytywne rzeczy więcej niż negatywne. Przekręca mózg, aby odwrócić logikę podczas czytania kodu źródłowego.Więc zamiast pisać:

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

Jawna określania zakresu: Według PMD website, to kontrowersyjny przepis. Możesz go nienawidzić, ktoś inny to lubi. Powinieneś uczynić wszystkie pola w swoich klasach prywatnymi. Wydaje się, że istnieje pole lub metoda (nie klasa) z widocznością paczki, np. coś takiego:

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

parametry końcowe: parametry metody należy ostateczna aby uniknąć przypadkowej zmiany przeznaczenia. To tylko dobra praktyka. Jeśli używasz środowiska Eclipse, funkcja obsługi treści zapewnia nawet poprawkę o nazwie "Zmień modyfikatory na ostateczne, jeśli to możliwe". Po prostu zaznacz cały kod w edytorze za pomocą Ctrl-a, a następnie naciśnij Ctrl-1.

Answer 2

Wszystko to wydaje się być małym ostrzeżeniem, które można wyłączyć.

1) on chce, aby odwrócić logikę

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

2) Jeśli pakiet jest naprawdę poprawna dostęp chcesz, nie ma modyfikator dostępu do dodania. Nie jestem dostatecznie zaznajomiony, aby wiedzieć, czy istnieje sposób na powstrzymanie tego konkretnego ostrzeżenia.

3) Problem z stylem. Niektórzy ludzie chcą finału wszystkiego, na czym może być. Inni sądzą, że dodaje zbyt dużo bałaganu za mało informacji. Jeśli jesteś w tym drugim obozie, wyłącz to ostrzeżenie.

Answer 3

Odnośnie pierwszego elementu (nierówność) istnieją dwa problemy:

1) Czytelność podwójnej negacji.

Powiedzmy, że masz:

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

Druga klauzula jest wykonywana, jeżeli "nie x nie jest równe y".

ten może być zapisane jako:

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

2) poprawności: gdy X i Y są nie-prymitywów pomocą if(!x.equals(y)) jest bezpieczniejsze. Jest to odpowiednik użycia == zamiast .equals() i może prowadzić do bardzo poważnych błędów.

Answer 4

Nie trzeba włączać wszystkich reguł. Wybierz niektóre z zasad, na które się zgadzasz i napraw kod, dopóki wszystkie ostrzeżenia nie zostaną usunięte.

- Zmodyfikuj go zgodnie z logiką if (x == y) ... else .... Po prostu unikaj negatywnych warunków, jeśli są to zapisy, tworzą kod trudniejszy do zrozumienia:

- Nie włączam tej zasady.

- Wiele osób deklaruje wiele pól i zmiennych końcowych. Zwłaszcza, gdy chcą się upewnić lub wyrazić, że wartość zmiennej nie zostanie zmieniona w metodzie. Jeśli ci się to nie podoba, wyłącz tę regułę.

Answer 5

Możesz również użyć // NOPMD na końcu dowolnej linii, w której nie chcesz sprawdzać zasad PMD.

Na przykład na powyższym danym kodem można stłumić czek PMD dając,

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

Należy pamiętać, że powyższy komentarz może dyskretnie tłumić inne ostrzeżenia w samym linii.