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

Question

Я использую 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 указал с этим предупреждением?

Answer 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 website, это спорное правило. Вы можете ненавидеть, кому-то это нравится. Что вы должны сделать, так это сделать все поля внутри ваших классов частными. Кажется, что есть поле или метод (не класс) с видимостью пакета, например. что-то вроде этого:

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

Окончательные параметры: Параметры метода должны быть окончательными, чтобы избежать случайного переназначение. Это просто хорошая практика. Если вы используете Eclipse, средство поддержки контента даже предоставляет быстрое исправление «Изменить модификаторы в финал, где это возможно». Просто выберите весь код в редакторе с помощью Ctrl-a, а затем нажмите Ctrl-1.

Answer 2

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

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

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

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

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

Answer 3

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

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

Скажем, у вас есть:

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

Второе условие выполняется, если «не х не равно у».

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

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