Comments 25
Молодцы!
А я правильно понимаю, что в Intellij Idea это в принципе все встроено по-умолчанию?
Возможно, но мы используем Eclipse, так как он является стандартом для нашей команды.
Вот это действительно фашизм — заставлять всех людей пользоваться одной средой разработки.
Когда в команде все согласны — это не проблема. Настаиваю на том, что провеки представлены в плагине лишь для удобства. Их легко можно переделать, как расширение в checkstyle-maven-plugin и счатье будет всем, кто использует maven. Опять фашизм на сонове билд машины :) Фашизм можно найти везде, поэтому так и назвали данную статью. А как вы воспользуетесь нашими наработками, это уже дело ваше. Мы надеемся, что вышепересиленные проверки попадут в общий релиз Checkstyle, и тогда сачтье будет всем.
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
Idea мееет похвальный список проверок, но все же НЕ все там есть:
ForbidAnnotationCheck
VariableDeclarationUsageDistanceCheck
AbbreviationAsWordInNameCheck
Более того, проверки в Идее, насколько я понимаю, не могут быть использованы в билдах и другими тулзами: maven (for maven report site) and Sonar,…
Наличие в Идее встроенной поддержки DSM не помешало нам начать разработку мавен плагина для этого
способа анализа зависимомтей (см. наш репозорий), но об этом уже в другой статье.
In Idea:
AvoidNotShortCircuitOperatorsForBooleanCheck
AvoidConstantsInInterfacesCheck
AvoidHidingCauseExceptionCheck
IllegalCatchCheck
OverridableMethodInConstructorCheck
ReturnBooleanFromTernary
ReturnNullInsteadOfBoolean
а чем это лучше codestlye в билд скрипте? всё равно же билд навернётся, что, в принипе, и является конечной целью?
Это просто другой, более удобный подход, использование которого позволяет исправлять код еще НА ЭТАПЕ его написания!!! Но если вам удобен процесс: построить проект > взять файл, найти и исправить в нем warning сообщения > построить проект > взять файл… то вы можете взять jar файл с нашего проекта и использовать его в своем билд скрипте. Проект с чистым jar-ом называется checkstyle-sevntu. Проект checkstyle-sevntu-plugin используется для плагина в Eclipse.
грош цена такому стилю, который надо постоянно исправлять. К принятому стилю надо привыкнуть за пару дней, а потом уже в одном и том же стиле код колбасить. А вот разработчикам, которые ему не следуют, надо создать максимум неудобств, чтобы писали правильно :)
Плагин помогает команде создать и контролировать стиль, подсвечивать проблемные участки и исправлять код. Смена стиля — это уже проблемы команды, а не утилит для его проверки.
а я контроль и имел ввиду. Смена — это для вновь пришедшего в команду
Стиль — не религия, и бывает такое, что новые люди привносят новые интресные случаи, которые приводят к разногласия в команде. Стиль можно дополнить также, как добавляются правила в Code Standard, если это не было оговорено и как бы очевидным это не казалось.
Пример: использование меток (goto). Новый человек использовал их для якобы оптимизации и почти обоснованно. Но заметить это не сразу можно. Когда стали разбираться — решили вопрос без меток, метки забанили Чевстайлом — изменение в стиле.
Пример: использование меток (goto). Новый человек использовал их для якобы оптимизации и почти обоснованно. Но заметить это не сразу можно. Когда стали разбираться — решили вопрос без меток, метки забанили Чевстайлом — изменение в стиле.
стиль — это не религия, это стандарт. Если такого стандарта нет, то и checkstyle не нужен. И, поверьте, в такоп проетке потом ковыряться — одно «удовольствие»…
Какие бы интересные случаи не были в конце концов стандарт утрясётся в каком-либо виде и новые разработчики доkжны прописанным стандартам и следовать.
Какие бы интересные случаи не были в конце концов стандарт утрясётся в каком-либо виде и новые разработчики доkжны прописанным стандартам и следовать.
А есть ли у вас полный стандарт для кода, полностью прописаный по всем контрукциям классов? И где гарантия того, что новый разработчик сразу поймет и запомнит его полностью? А править и делать code review регулярно — у вас, возможно, не будет времени на то, что можно автоматизировать. Опыт увсех разный, и, частенько, даже опытные программсты допускают ошибки или просто забывают в суете фиксов.
а зачем покрывать ВСЕ кейзы стандартом? Документ должен быть простым для прочтения и понимания.
И именно что бы в ходе code review не тыкать пальцем в скобки и нужен стандарт. Цель ревью — проверка написанного функционала, хотя би и поверхностная. И если времени на ревью не хвататает — оно потом отлично находится на последующий багфиксинг.
А еще «опытные» программисы в суете фиксят баг и коммитят его. И только потом запускают регрессионные тесты. А вот потом начинается самое интересное…
А нормальному разработчику неверный codestyle глаз режет, потому что начинаешь задумываться, а что этим тут хотели сказать?
И именно что бы в ходе code review не тыкать пальцем в скобки и нужен стандарт. Цель ревью — проверка написанного функционала, хотя би и поверхностная. И если времени на ревью не хвататает — оно потом отлично находится на последующий багфиксинг.
А еще «опытные» программисы в суете фиксят баг и коммитят его. И только потом запускают регрессионные тесты. А вот потом начинается самое интересное…
А нормальному разработчику неверный codestyle глаз режет, потому что начинаешь задумываться, а что этим тут хотели сказать?
То что нормальному программисту глаз режит — то еще не совсем нормальному программисту на глаз приятно и очень удобно кодируется :).
Я рад за вас что у вас таких нет в команде, но мир не идеален.
Я рад за вас что у вас таких нет в команде, но мир не идеален.
вот таких ненормальных надо переучивать, а не жизнь облегчать :)
Зачем же тратить время на переучивание, если можно просто дать использовать Чекстайл. Он сам все подскажет, где нужно исправить код, как лучше писать. Это и является одной из его целей: показать разработчику, как нужно писать код правильно, и заставить его следовать правилам, описанным в чеках. Как раз в таком подходе жизнь облегчается не для «ненормального», а для всей команды.
Переучиванием занимается Чекстайл: грамотному подсказывает, несовсем грамотному показывает, что ему нужно прогулить, а упрямца ловит сразу на месте, и можно сконфигурировать Checkstyle так, что бы он давал ERROR, тем самым ломая упрямцу локальную компиляцию — он начнет возмущаться и вот тут-то вы ему все и объясните.
Профит — экономия времени, нервов.
Переучиванием занимается Чекстайл: грамотному подсказывает, несовсем грамотному показывает, что ему нужно прогулить, а упрямца ловит сразу на месте, и можно сконфигурировать Checkstyle так, что бы он давал ERROR, тем самым ломая упрямцу локальную компиляцию — он начнет возмущаться и вот тут-то вы ему все и объясните.
Профит — экономия времени, нервов.
Кстати, а вот PMD или Findbugs во встроенном режиме в эклипесе — это уже гораздо лучше. Ждём с нетерпением :)
Пересел неделю назад с Java на Erlang! Все время радуюсь!
Sign up to leave a comment.
Фашизм в коде. Часть вторая