Предупреждения PMD - Code Analyzer

Я использую 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. Должен ли я добавить конечное ключевое слово ко всем местам, которые PMD указал с этим предупреждением?

Ответ 1

Избегайте отрицания: Вместо 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, средство поддержки контента даже предоставляет быстрое исправление, называемое "Модификаторы изменений до финала, где это возможно". Просто выберите весь код в редакторе с помощью Ctrl-a, а затем нажмите Ctrl-1.

Ответ 2

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

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

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

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

Ответ 3

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

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() и может привести к очень серьезным ошибкам.

Ответ 5

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

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

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

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