Каковы рекомендации по реализации проверок Java Checkstyle?
Я новичок в инструментах статического анализа кода для java, таких как CheckStyle. Я скачал пакет Checkstyle и вижу 2 набора чеков:
- checkstyle_checks.xml
- sun_checks.xml .
Я сравнил их и geosoft_checks.xml к главному списку всех доступных в checkstyle ...по существу 4 таблица полное внешнее соединение, чтобы увидеть, какие проверки были включены в большинство из 3 источники.
Чеки |Источник
-----------|--------------------------------------------------------
134.......| все доступные
75.........| checkstyle_checks.xml (плюс фильтр подавления, указывающий на подавление.xml )
63.........| sun_checks.xml
73.........| geosoft_chekcs.xml (после удаления 4 которые не работают в стиле checkstyle 5.7)
- двойная блокировка
- PackageHtml
- TabCharacter
- GenericIllegalRegexp
Я только сделал анализ sun_checks и geosoft_checks, чтобы определить, какие из них я могу безопасно удалить на основе фактических результатов в базе кода (конечно, кто-то может прийти и нарушить одну из многих проверок, не включенных ни в одну из них)
Существуют ли последние рекомендации, для которых проверки чтобы включить то, что не будет излишне расстраивать команду разработчиков ? Расширили ли люди checkstyle полезными проверками, которые были возвращены в сообщество opensource ?
1 ответ:
Это отличный вопрос, и он требует ответа гораздо дольше, чем простой пост SO. Дай мне еще попробовать.
Во-первых, нет общепринятого общего руководства, которое помогло бы вам. Любой, кто приходит к вам с такой рекомендацией, на самом деле продает только свои собственные вещи. Итак, я твердо верю, что нет ничего, что вы могли бы просто взять и активировать и сделать. Это немного грустно, но мы здесь.
sun_checks в основном исторические и имеют фокус о форматировании и именовании. Они, вероятно, все еще лучший старт, если у вас нет ничего другого. Checkstyle_checks - это то, что команда Checkstyle использует для проверки собственного кода. Я не знаю geosoft_checks, которые, по-видимому, являются хорошо документированной формой локального руководства. Существует такжеGoogle Java Style , который стал довольно популярным, но у afaik пока нет соответствующего набора правил Checkstyle.
Checkstyle-это инструмент, который может сделать гораздо больше, чем просто проверить стиль кода Java. Вы уже показали, что существует почти в два раза больше доступных проверок, чем используется в наборах правил. Мой собственный набор правил использует 99 проверок, но он очень адаптирован к решению, которое мы создаем.
Я считаю, что если вы серьезно занимаетесь статическим анализом кода, то однажды вам придется просмотреть список всех доступных проверок и составить свой собственный набор правил. И вы будете добавлять к нему по мере развития проекта, чтобы охватить все больше и больше случаев, когда вы определили потенциальные ошибки в создаваемом решении. Тонкая настройка и добавление к профилю Checkstyle будет постоянной задачей (скажем, час в неделю).Если вы хотите избежать "ненужного разочарования команды разработчиков", самый важный аспект должен быть ясным, хорошо документированным и последовательным в отношении ваших правил. Кроме того, интегрируйте Checkstyle с вашей ночной сборкой и/или системой управления версиями.
Наиболее заметными расширениями Checkstyle являются SevNTU Checkstyle иCheckstyle Addons . Ведущий парень SevNTU Checkstyle также является главным коммиттером Checkstyle сегодня, так что, возможно, они сольются когда-нибудь в будущем.