Checkstyle и PMD только как совет

Как мне настроить использование результатов pmd и checkstyle только в качестве рекомендаций и отключить их на сервере сборки? И будет ли это плохой практикой?

И pmd, и checkstyle предлагают ценные советы, и я хочу продолжать их использовать.

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

  • Тестовые классы содержат много статических импортированных mockito и junit, мне всегда приходится добавлять @SuppressWarnings ("PMD.TooManyStaticImports").

  • Поля тестируемого класса должны быть заполнены фиктивными объектами, они нигде в тесте не используются, но должны быть объявлены и аннотированы с помощью @Mock для правильной работы тестируемого класса. Добавьте @SuppressWarnings ("PMD.UnusedPrivateField").

  • В тестовых классах у меня будут методы для создания объектов из длинного списка параметров, например: createPerson (String firstname, String lastname, int shoesize, String favouritecolor, ...). Эти объекты обычно создаются из базы данных или XML. Добавьте @SuppressWarnings ("PMD.ParameterNumberCheck").

  • Иногда моя документация будет такой: «Этот метод гарантирует, что X в следующих 3 случаях: \ n ...». Очевидно, это недопустимо, так как первое предложение должно заканчиваться точкой.

  • Родительский класс X имеет некоторое поле y, которое необходимо и используется всеми его дочерними элементами, но стиль проверки не позволит это, если это поле не доступ через метод (getY ()). Это просто неестественно, ИМО.

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

Так будет ли это решение для генерации предупреждений, но не позволяющее нарушениям checkstyle и pmd сбой сборки?


java checkstyle software-quality pmd
person Ivana    schedule 27.09.2017    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Тест-классы содержат ...
Тестируемый класс ...
В тестовых классах ...

Мне кажется, вы должны подавить эти проверки в своем тестовом коде, поскольку вы с ними не согласны.

Это обычное явление, например, в Checkstyle мы не документируем наш тестовый код, но наш основной код документирует все. Чтобы обойти это для PMD, мы разделили нашу конфигурацию между тестовой и main. Чтобы обойти это в Checkstyle мы подавляем нарушения для тестового каталога. Вы также можете посмотреть параметры проверок и посмотреть, есть ли способ настроить его так, чтобы игнорировать ваши обращения.

Иногда моя документация будет такой: «Этот метод гарантирует, что X в следующих 3 случаях: \ n ...».

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

У родительского класса X есть поле y, которое нужно и использовать всем его дочерним элементам, но checkstyle не позволит это сделать, если к полю не осуществляется доступ через метод (getY ()). Это просто неестественно, ИМО.

Раз уж вам это совсем не нравится, то просто отключите проверку защищенных полей. Если вы посмотрите документацию для VisibilityModifier, вы можете изменить protectedAllowed на true и получить его игнорируйте эти конкретные случаи.

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

Мне просто кажется, что вы не настраиваете эти инструменты в соответствии со своими предпочтениями, а просто пытаетесь использовать конфигурацию по умолчанию.

person rveach    schedule 27.09.2017