Спасибо за статью, но, как по мне, не хватает примеров: было так, после ряда оптимизаций стало вот так, по размеру выиграли столько-то, по производительности потеряли столько-то.
Используем Sonar + Checkstyle. Недавно писал статью об интеграции и использовании своих кастомных чеков в Sonar как расширение к существующему Checkstyle плагину. Кому интересно, делюсь ссылкой: Custom Checkstyle’s checks integration into SonarQube
Зачем же тратить время на переучивание, если можно просто дать использовать Чекстайл. Он сам все подскажет, где нужно исправить код, как лучше писать. Это и является одной из его целей: показать разработчику, как нужно писать код правильно, и заставить его следовать правилам, описанным в чеках. Как раз в таком подходе жизнь облегчается не для «ненормального», а для всей команды.
Переучиванием занимается Чекстайл: грамотному подсказывает, несовсем грамотному показывает, что ему нужно прогулить, а упрямца ловит сразу на месте, и можно сконфигурировать Checkstyle так, что бы он давал ERROR, тем самым ломая упрямцу локальную компиляцию — он начнет возмущаться и вот тут-то вы ему все и объясните.
www.jetbrains.com/idea/documentation/inspections.jsp
Idea мееет похвальный список проверок, но все же НЕ все там есть:
ForbidAnnotationCheck
VariableDeclarationUsageDistanceCheck
AbbreviationAsWordInNameCheck
Более того, проверки в Идее, насколько я понимаю, не могут быть использованы в билдах и другими тулзами: maven (for maven report site) and Sonar,…
Наличие в Идее встроенной поддержки DSM не помешало нам начать разработку мавен плагина для этого
способа анализа зависимомтей (см. наш репозорий), но об этом уже в другой статье.
In Idea:
AvoidNotShortCircuitOperatorsForBooleanCheck
AvoidConstantsInInterfacesCheck
AvoidHidingCauseExceptionCheck
IllegalCatchCheck
OverridableMethodInConstructorCheck
ReturnBooleanFromTernary
ReturnNullInsteadOfBoolean
То что нормальному программисту глаз режит — то еще не совсем нормальному программисту на глаз приятно и очень удобно кодируется :).
Я рад за вас что у вас таких нет в команде, но мир не идеален.
Когда в команде все согласны — это не проблема. Настаиваю на том, что провеки представлены в плагине лишь для удобства. Их легко можно переделать, как расширение в checkstyle-maven-plugin и счатье будет всем, кто использует maven. Опять фашизм на сонове билд машины :) Фашизм можно найти везде, поэтому так и назвали данную статью. А как вы воспользуетесь нашими наработками, это уже дело ваше. Мы надеемся, что вышепересиленные проверки попадут в общий релиз Checkstyle, и тогда сачтье будет всем.
А есть ли у вас полный стандарт для кода, полностью прописаный по всем контрукциям классов? И где гарантия того, что новый разработчик сразу поймет и запомнит его полностью? А править и делать code review регулярно — у вас, возможно, не будет времени на то, что можно автоматизировать. Опыт увсех разный, и, частенько, даже опытные программсты допускают ошибки или просто забывают в суете фиксов.
Стиль — не религия, и бывает такое, что новые люди привносят новые интресные случаи, которые приводят к разногласия в команде. Стиль можно дополнить также, как добавляются правила в Code Standard, если это не было оговорено и как бы очевидным это не казалось.
Пример: использование меток (goto). Новый человек использовал их для якобы оптимизации и почти обоснованно. Но заметить это не сразу можно. Когда стали разбираться — решили вопрос без меток, метки забанили Чевстайлом — изменение в стиле.
Спасибо, используем уже давно, но проверки эти мы делаем для того, что бы не дожидатся релиза Checkstyle и еще потом релиза от Sonar. Но все модули высылаются как патчи в основной проект — не все чеки принимаются, и ждать мы не можем долго.
Плагин помогает команде создать и контролировать стиль, подсвечивать проблемные участки и исправлять код. Смена стиля — это уже проблемы команды, а не утилит для его проверки.
Это просто другой, более удобный подход, использование которого позволяет исправлять код еще НА ЭТАПЕ его написания!!! Но если вам удобен процесс: построить проект > взять файл, найти и исправить в нем warning сообщения > построить проект > взять файл… то вы можете взять jar файл с нашего проекта и использовать его в своем билд скрипте. Проект с чистым jar-ом называется checkstyle-sevntu. Проект checkstyle-sevntu-plugin используется для плагина в Eclipse.
Есть желание помочь — помогите в разработке нашего проекта: http://sevntu-checkstyle.github.com/sevntu.checkstyle/.
На wiki вы найдете всю необходимую информацию, чтобы быстро начать разработку: https://github.com/sevntu-checkstyle/sevntu.checkstyle/wiki
Переучиванием занимается Чекстайл: грамотному подсказывает, несовсем грамотному показывает, что ему нужно прогулить, а упрямца ловит сразу на месте, и можно сконфигурировать Checkstyle так, что бы он давал ERROR, тем самым ломая упрямцу локальную компиляцию — он начнет возмущаться и вот тут-то вы ему все и объясните.
Профит — экономия времени, нервов.
Idea мееет похвальный список проверок, но все же НЕ все там есть:
ForbidAnnotationCheck
VariableDeclarationUsageDistanceCheck
AbbreviationAsWordInNameCheck
Более того, проверки в Идее, насколько я понимаю, не могут быть использованы в билдах и другими тулзами: maven (for maven report site) and Sonar,…
Наличие в Идее встроенной поддержки DSM не помешало нам начать разработку мавен плагина для этого
способа анализа зависимомтей (см. наш репозорий), но об этом уже в другой статье.
In Idea:
AvoidNotShortCircuitOperatorsForBooleanCheck
AvoidConstantsInInterfacesCheck
AvoidHidingCauseExceptionCheck
IllegalCatchCheck
OverridableMethodInConstructorCheck
ReturnBooleanFromTernary
ReturnNullInsteadOfBoolean
Я рад за вас что у вас таких нет в команде, но мир не идеален.
Пример: использование меток (goto). Новый человек использовал их для якобы оптимизации и почти обоснованно. Но заметить это не сразу можно. Когда стали разбираться — решили вопрос без меток, метки забанили Чевстайлом — изменение в стиле.