#java #checkstyle #pmd
#java #checkstyle #pmd
Вопрос:
У меня возникла проблема или я ищу правило checkstyle, которое подтвердит следующее. Это тривиальная проверка, но было бы полезным правилом, когда кто-то вручную изменяет имя get / set.
Я хочу иметь правило, которое будет проверять получение / наборы и выдавать ошибку, когда в коде встречается что-то подобное.
Пример: исходным атрибутом было описание. Но разработчику необходимо изменить его на ShortDescription, но он портит рефакторинг.
private String description;
public String getDescription() {
return description;
}
public void setShortDescription(String description) {
this.description = description;
}
Или, если есть какой-либо другой механизм правил, такой как Pmd, который может это зафиксировать. Или пользовательский набор правил, я думаю, я мог бы создать.
Ответ №1:
Хотя Checkstyle не распространяется, если PMD может быть опцией, существует тест BEANMEMBERSHOULDSERIALIZE, который жалуется, если есть какие-либо нестатические и нестационарные поля, у которых нет геттеров и установщиков, соответствующих соглашениям об именовании Java.
Комментарии:
1. ПРИЯТНО ..!!! Это звучит почти как идеальное решение. Быстрый способ проверки правильности получения / наборов для каждой нестатической переменной. Спасибо!! Я проверю это.
Ответ №2:
Стандартные проверки checkstyle не предлагают ничего подобного, и я не думаю, что такая проверка имеет большой смысл:
В вашем примере вы ожидаете сообщения о какой ошибке? Отсутствует установщик для description
свойства? Отсутствующее свойство для setShortDescription
установщика?
Как checkstyle должен знать свойства, для которых вы хотите иметь получатели / установщики? Я предполагаю, что вы не хотите иметь геттеры и сеттеры для всех ваших частных переменных.
Комментарии:
1. Я ожидаю, что при запуске этого типа правила произойдет сбой сборки. Ошибка будет «отсутствует setDescription для описания внутреннего поля, но найдена ссылка на setShortDescription. Во многих случаях для классов «pojo / domain» они обычно имеют семантику, такую как внутренние поля только «private», и имеют эквивалентный set / get для каждой внутренней переменной. Итак, да, на основе правила я бы хотел, чтобы проверялась каждая внутренняя переменная домена, кроме статики. Возможно в соответствии со спецификацией компонента. В некоторых случаях ошибки, подобные этой, просочились из-за простых ошибок. Эти ошибки являются дорогостоящими для последующего использования.