Предупреждения анализатора PMD-кода

Я использую PMD для анализа кода, и он выдает несколько высокоприоритетных предупреждений, которые я не знаю, как исправить.

1) Avoid if(x!=y)..; else...; но что мне делать, если мне нужна эта логика? То есть, мне нужно проверить, если x!=y? Как я могу рефакторинг?

2) Use explicit scoping instead of the default package private level. но класс действительно используется только внутри пакета. Какой модификатор доступа следует использовать?

3) Parameter is not assigned and could be declared final. должен ли я добавить ключевое слово final ко всем местам, на которые указал PMD с этим предупреждением?

14
code-analysis java pmd

5 ответов

избежать отрицания: вместо if( x!=y ) doThis() else doThat(), сначала проверьте положительный случай, потому что люди/люди, как правило, любят положительные вещи больше, чем отрицательные. Он скручивает мозг, чтобы изменить логику в уме при чтении исходного кода. Поэтому вместо этого напишите:

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

явное аналитическое исследование: по данным веб-сайт PMD, это спорное правило. Вы можете ненавидеть это, кому-то это нравится. Что вы должны сделать, это сделать все поля ваши занятия частные. Кажется, есть поле или метод (не класс) с видимостью пакета, например, что-то вроде этого:

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

окончательные параметры: параметры метода должны быть окончательными, чтобы избежать случайных перемещений. Это просто хорошая практика. Если вы используете Eclipse, content assist даже предоставляет quickfix под названием "измените модификаторы на final, где это возможно". Просто выделите весь код в редакторе с помощью Ctrl-A, а затем нажмите Сочетание клавиш Ctrl-1.

30

вам не нужно включать все правила. Выбрать некоторые правила, вы соглашаетесь и рефакторинг кода, пока все предупреждения удаляются.

1 - рефакторинг его в if (x == y) ... else ... логика. Просто избегайте негативных условий в if statments, они затрудняют понимание кода

2 - Я бы не включил это правило.

3 - многие люди объявляют много полей и переменных окончательными. Особенно, когда они хотят убедиться или выразить, что значение переменной не должно изменяться в методе. Если вам это не нравится, отключите это правило.

6

все это похоже на незначительные предупреждения, которые можно отключить.

1) он хочет, чтобы вы перевернули логику

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

2) Если пакет действительно правильный доступ, который вы хотите, нет модификатора доступа для добавления. Я недостаточно знаком, чтобы знать, есть ли способ подавить это конкретное предупреждение.

3) проблема стиля. Некоторые люди хотят финал на все, что он может быть на. Другие считают, что это добавляет слишком много беспорядка к небольшой информации. Если вы находитесь в последний лагерь, выключи это предупреждение.

4

что касается первого пункта (неравенства) есть два вопроса:

1) читаемость двойного отрицания.

скажите, что у вас есть:

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

второе предложение выполняется, если "не x не равно y".

Это можно переписать как:

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

2) правильность: если x и y не являются-примитивами, используя if(!x.equals(y)) безопаснее. Это эквивалент использования = = вместо .Equals() и может привести к очень серьезным ошибкам.

4

вы также можете использовать // NOPMD в конце любой строки, где вы не хотите проверять правила PMD.

например, для приведенного выше кода Вы можете подавить проверку PMD, указав,

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

имейте в виду, что приведенный выше комментарий может молча подавлять другие предупреждения в то же самое линии.

1