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

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.Что Касается 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() может быть null? Код вложен в while (objBRdr.ready()) тест, и до сих пор у меня нет никаких проблем.

обновление 1: 2.2 был исправлен, когда я заменил код:

strLine = objBRdr.readLine();
    if (strLine != null) {
        strLine = strLine.trim();
    }
7
eclipse eclipse-plugin findbugs java pmd

2 ответов

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

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

эти файлы расположены в rulesets каталог распределения PMD. При использовании PMD с Eclipse проверьте настройка PMD.

1.2 это нужно следуйте этим советам, предупреждение?

A class which only has private constructors should be final

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

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

1.3 что это значит?

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

сложность-это количество точек принятия решения в методе плюс один для записи метода. Решение очки 'если', 'А', 'К', и 'дело лейблов. Вообще, 1-4 низкая сложность, 5-7 показывает умеренную сложность, 8-10 высокая сложность, а 11+ - это очень высокая сложность.

сказав это, я просто процитирую некоторые части совокупная цикломатическая сложность бессмысленна:

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

потому что меры цикломатическая сложность pathing в методе, каждый метод имеет по крайней мере, цикломатическая сложность Один, правильно? Итак, следующий метод getter имеет значение CCN 1:

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

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

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

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

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

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

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

не уверен, что вы не об этом.

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

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

2.2 [...] Immediate dereference of the result of readLine()

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

9

здесь какая-то идея / ответ

1.4 какова причина присвоения null объекту? Если вы повторно используете ту же переменную, нет причин устанавливать ее в значение null раньше.

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

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

2