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

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

from datetime import date, timedelta

def get_first_dow(year, week):
    d = date(year, 1, 1)
    d = d - timedelta(d.weekday())
    dlt = timedelta(days = (week - 1) * 7)
    return d + dlt
7
задан Svante 11 October 2009 в 17:06
поделиться

2 ответа

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

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

Эти файлы расположены в каталоге наборов правил дистрибутива PMD. При использовании PMD с Eclipse проверьте Настройка PMD .

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

 Класс, который имеет только частные конструкторы, должен быть окончательным

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

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

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

 Класс «Dog» имеет цикломатический Сложность 3 (высшая = 17)

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

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

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

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

 public Account getAccount () {
 вернуть this.account;
}

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

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

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

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

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

 Присвоение объекту значения null - это запах кода. Рассмотрите возможность рефакторинга.

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

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

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

2.2 [...] Немедленное разыменование результата readLine ()

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

9
ответ дан 6 December 2019 в 23:10
поделиться

Here some idea / answer

1.4 What is the reason to assign null to a object? If you reuse the same variable, there's not reason to set it to null before.

2.1 The reason about this warning, is to be sure that all your instance of the class Main have the same static fields. In your Main class, you could have static Calendar appCalendar = Calendar.getInstance() ;

about your 2.2 you're right, with the null check, you are sure that you'll not have any NullPointerException. We never know when your BufferedReader can block/trash, this doesn't happen often (in my experience) but we never know when a hard drive crash.

2
ответ дан 6 December 2019 в 23:10
поделиться
Другие вопросы по тегам:

Похожие вопросы: