анализаторы кода: PMD и FindBugs

Question

1. Что касается PMD:

1.1 Как установить проверку PMD, чтобы игнорировать некоторые из них, как «Имя переменной слишком коротка, или слишком долго», «Удалить пустой конструктор и т. д. "- и если я это сделаю, появится другое предупреждение, в котором говорится, что класс должен иметь некоторые статические методы. В принципе, класс был пуст, для более позднего развития, и мне нравится оставлять его таким образом на данный момент.

1.2 Не забудьте ли следовать этому предупреждению?

A class which only has private constructors should be final 

1.3 Что это должно означать?

The class 'Dog' has a Cyclomatic Complexity of 3 (Highest = 17) 

1.4 Как насчет этого? Я хотел бы изменить это, но ничего не пересекает мой ум в данный момент относительно изменения:

Assigning an Object to null is a code smell. Consider refactoring. 

2.Regarding FindBugs:

2,1 действительно ли это так плохо, чтобы писать в статическом поле, в какой-то момент позже его объявления? Следующий код дает мне предупреждение:

Main.appCalendar = Calendar.getInstance(); 
Main.appCalendar.setTimeInMillis(System.currentTimeMillis()); 

где appCalendar является статической переменной.

2,2 Этот код:

strLine = objBRdr.readLine().trim(); 

дает предупреждение:

Immediate dereference of the result of readLine() 

где objBRdr является BufferedReader(FileReader). Что может случиться? readLine() может быть пустым? Код вложен в while (objBRdr.ready()) тест, и до сих пор у меня там нулевые проблемы.

Update1: 2,2 был зафиксирован, когда я заменил код с:

strLine = objBRdr.readLine(); 
    if (strLine != null) { 
     strLine = strLine.trim(); 
    } 

Answer 1

1,1 Как установить проверку PMD [...]

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

Эти файлы находятся в каталоге rulesets дистрибьютора PMD. При использовании PMD с Eclipse отметьте Customizing PMD.

1.2 Необходимо ли следовать этому предупреждению?

A class which only has private constructors should be final 

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

Так что на самом деле невозможно получить подкласс класса, каждый из которых является закрытым. Таким образом, маркировка такого класса, как final, является хорошей идеей (но не обязательной), поскольку она явно препятствует подклассу.

1.3 Что это должно означать?

The class 'Dog' has a Cyclomatic Complexity of 3 (Highest = 17) 

Сложность является количеством точек принятия решений в методе плюс один для записи методы. Точками принятия решения являются «if», «while», «for» и «case labels». Как правило, 1-4 - низкая сложность, 5-7 - умеренная сложность, 8-10 - высокая сложность, а 11+ - очень высокая.

После того, что сказал, я просто процитирую некоторые части Aggregate Cyclomatic complexity is meaningless:

[...] Этот показатель имеет смысл только в контексте одного метода. Упоминание о том, что класс имеет Cyclomatic сложности X, по существу бесполезен.

Поскольку цикломатическая сложность измеряет Pathing в методе, каждый метод имеет по крайней мере, цикломатическая сложность 1, правильно? Таким образом, следующий метод геттер имеет значение CCN 1:

public Account getAccount(){ 
    return this.account; 
} 

Это ясно из этого метода буги что account является свойством этого класса. Теперь представьте, что этот класс имеет 15 свойств и следует типичной парадигме getter/setter для каждого свойства , и это единственные доступные методы. Это означает, что класс имеет 30 простых методов, каждый из которых имеет значение Cyclomatic сложности 1. Совокупное значение класса тогда равно 30.

Имеет ли это значение какое-либо значение, человек? Конечно, смотреть его со временем может что-то интересное; однако сам по себе, как совокупное значение, он по существу не имеет смысла. 30 для класса ничего не значит, 30 для метода что-то означает.

В следующий раз, когда вы оказываетесь чтением Copasetic совокупного цикломатического значения сложности для класса, убедитесь, что вы понимаете, как много методов класс содержит. Если совокупность Cyclomatic сложность значение класса 200 - оно не должно поднять любые красные флаги, пока вы не узнаете количество методов . Более того, если вы обнаружите, что количество методов еще не установлено Значение сложности Cyclomatic высокое, вы почти всегда найдете сложность , локализованную по методу. Право на!

Так что это правило PMD должно приниматься с осторожностью (и на самом деле не очень ценно).

1.4 Как насчет этого? Я хотел бы изменить это, но ничего не пересекает мой ум в данный момент относительно изменения:

Assigning an Object to null is a code smell. Consider refactoring. 

Не уверен, что вы не получите об этом.

2.1 Неужели так плохо писать в статическое поле, в какой-то момент позже его объявления? [...]

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

2,2 [...] Immediate dereference of the result of readLine()

Если нет больше строк текста для чтения, readLine() возвратит нуль и разыменования, который будет генерировать исключения нулевого указателя. Поэтому вам действительно нужно проверить, равен ли результат.

Answer 2

Вот некоторые идеи/ответ

1,4 В чем причина, чтобы присвоить нуль на объект? Если вы повторно используете одну и ту же переменную, нет причин устанавливать ее до нуля.

2.1 Причина этого предупреждения заключается в том, чтобы убедиться, что все ваши экземпляры класса Main имеют одинаковые статические поля. В вашем основном классе у вас может быть статический календарь appCalendar = Calendar.getInstance();

о вашем 2.2 вы правы, с нулевой отметкой, вы уверены, что у вас не будет исключения NullPointerException. Мы никогда не знаем, когда ваш BufferedReader может блокировать/мусор, это часто случается (по моему опыту), но мы никогда не знаем, когда сбой жесткого диска.