Pull to refresh

Фашизм в коде. Часть вторая

Reading time 4 min
Views 3.9K
imageВ своем предыдущем посте мой коллега попытался расскрыть идею положительного влияния "фашизма" в коде на примере одного из проверочных модулей (чеков). Вместе с примером была предоставлена наша сборка плагина с некоторым расширением. Наша команда разработала ряд новых чеков и упростила установку в Eclipse.

«Фашизм» в коде посредством использования проекта Checkstyle… Что может быть лучше такой идеологии? Половина, а то и больше замечаний, которые делаются при обычном ревью кода программистами может быть исправленна (недопущена) еще на этапе написания кода. Применение проверочных модулей оказывает огромное влияние на внешний вид и читабельность, а значит, и поддерживаемость программ. Существует масса книг в которых авторы делатся опытом как не надо писать код и показывают самые популярные ошибки. Все уважающие себя программисты читали такие книги как «Effective Java» J.Bloch, «Java Puzzlers» J.Bloch, Java Pitfalls и …. Но все ли советы вы используете из них? Как показывает практика даже серьезные программисты допускают банальные ошибки.

После первого релиза, мы решили упростить процесс использования наших наработок. Решением было организовать свой проект с чеками, невошедшими в релиз Checkstyle, в виде дополнения (feature) к плагину Checkstyle для Eclipse. Упрощенный процесс установки свелся к:
  1. Ставим плагин плагин Checkstyle (update-site: eclipse-cs.sourceforge.net/update ), если он еще не стоит.
  2. Ставим наше дополнение (update-site: sevntu-checkstyle.github.com/sevntu.checkstyle/update-site ).

Получаем в настройках чекстайла группу с нашими проверками:

image
Рисунок 1 – Диалоговое окно конфигурации проверочных модулей (чеков)

После установки нашего модуля он появляется в списке существующих под именем "SevNTU checks". Таким образом, не дожидаясь основного релиза Checkstyle, мы можем полноценно использовать наши чеки для автоматического контроля качества Java-кода. Вкратце опишу последние из них.

Проверочный модуль "ForbidAnnotationCheck" – производит проверку на использование аннотаций, указанных в конфигурации чека. Например:

@Autowired
private DataSource dataSource;


С помощью этого чека можно запретить @Autowired на полях класса, и заставить программиста не поленитья и воспользоваться сеттером для @Autowired.

Проверочный модуль "VariableDeclarationUsageDistanceCheck" – используется для проверки расстояния между определением переменной и ее первым использованием. Если расстояние превышает некоторое, изначально заданное, значение, то пользователь информируется сообщением. Проверка производится для случая, когда определение переменной и ее использование находятся в одной области видимости. Включает следующие опции:
  1. allowedDistance – установка допустимого расстояния между определением переменной и ее первым использованием.
  2. ignoreVariablePattern – установка регулярного выражения для имен переменных, исключаемых из проверки.
  3. validateBetweenScopes – проверка расстояния для случая, когда определение переменной и ее использование находятся в разных областях видимости.
  4. ignoreFinal – игнорирование переменных, в определении которых используется ключевое слово final.

Проверочный модуль "AbbreviationAsWordInNameCheck" – производит проверку имен классов, интерфейсов, переменных и методов на нахождение в них аббревиатур с заглавными буквами. Пример: «XMLReader» должен быть «XmlReader». Включает следующие опции:
  1. allowedAbbreviationLength – разрешимое число идущих подряд заглавных букв в аббревиатуре. Например: "interface ABCDInterface". Здесь аббревиатура "ABCD" и слово "Interface". Для того, чтобы данный случай игнорировался, в данной опции следует поставить число идущих подряд заглавных букв в аббревиатуре, равное 4.
  2. allowedAbbreviations – список аббревиатур, которые будут игнорироваться.
  3. ignoreFinal – игнорирование переменных, в определении которых используется ключевое слово final.
  4. ignoreStatic – игнорирование полей, в определении которых используется ключевое слово static.

Проверочный модуль "OverridableMethodInConstructorCheck" – производит проверку на вызов переопределенных (overridable) public/protected методов из конструктора, readObject and clone мктодов класса. Проверяется весь стек вызовов, например, constructor -> private method -> public/protected method.

Проверочный модуль "ReturnNullInsteadOfBoolean" – служит для отслеживания ситуаций, когда в декларации метода тип возвращаемого объекта – Boolean, но сам метод может вернуть null.

Проверочный модуль "AvoidNotShortCircuitOperatorsForBooleanCheck" – производит проверку условных выражений на использование bitwise операторов ("|", "&", "|=", "&=") вместо обычных для булевого типа операторов short-circuit логики.

Проверочный модуль "AvoidConstantsInInterfacesCheck" – константы следует определять в классах (см. J.Bloch «Effective Java» Item 19: Use interfaces only to define types).

Проверочный модуль "AvoidHidingCauseExceptionCheck" – информирует пользователя о том, что тот скрыл причину исключительной ситуации. Например:

catch (IllegalStateException e) {
// your code
throw new RuntimeException();
}


В данном фрагменте кода происходит скрытие исключения "IllegalStateException".

Проверочный модуль "IllegalCatchExtendedCheck" – производит проверку блоков catch() на захват исключений типа java.lang.Exception, java.lang.Error или java.lang.RuntimeException. Включает следующие опции:
  1. allowThrow – игнорирование блока catch(), если в нем выбрасывается новое исключение.
  2. allowRethrow – игнорирование блока catch(), если в нем выбрасывается отловленное исключение.

Проверочный модуль "ReturnBooleanFromTernary" – производит проверку ветвей тернарного оператора. При нахождении 'true' или 'false', как единственного содержимого ветки, информирует пользователя сообщением. Например, вместо строки "boolean b = a ? false : true;" лучше использовать "b = !a;".

Если вы считае эти проверки прописными истинами, которые все знают – проверьте свой код и вы будете удивлены!!!

Кого заинтересовала данная тема, да и кому интересно опробовать наши чеки на своих проектах, приглашаю на сайт проекта. Wiki заметки «в помощь разработчику» здесь.

Благодарю за внимание!

P.S. FindBug, PMD, Sonar… мы знаем о существовании этих продуктов, и некоторые идеи были заимствованы из них. Но по ряду причин мы сфокусировали свои силы имеенно на Сheckstyle.
Tags:
Hubs:
+21
Comments 25
Comments Comments 25

Articles