Всем привет.

Есть ли среди нас люди активно использующие PMD у себя в проектах? Какие рулы применяете наиболее часто? Какие считаете самыми важными? Приведите, пожалуйста, свою классификацию рулов по приоритетам. Думаю, этот опыт будет многим полезен. Обсудим, составим коллективный набор =)

У нас с недавних пор Sonar. Вот список наших самых популярных мессаджей после первого запуска (устаревший, многое уже исправлено). Часть решается настроками форматтеров. Добавил свои комментарии.


Проект 1:
 
1. Confusing Ternary (предлагается избегать конструкции a!=b ? x : y. Я не согласенб потому что считаю a!=null ? x : y лучше, чем a==null ? y : x)
2. Illegal Catch (предлагается не ловить базовые классы исключений. Это нужно не так уж редко, поэтому я против сведения её к 0, но мониторить надо)
3. Uncommented Empty Constructor (в принципе, я "за", только работает это правило в Sonar неправильно  )
4. Short Variable (имена типа id. Я против их запрета)
5. Avoid Throwing Raw Exception Types (не делать new RuntimeException() - тут я согласен)

Проект 2:

1. Indentation (количество пробелов на Tab - было разным у разработчиков)
2. Javadoc Method (разные нарушения, чаще всего - отсутствие явадока)
3. Javadoc Variable (аналогично)
4. Line Length (по дефолту максимальная длина - 80, имхо, это неправильно. 120 нормально)
5. Long Variable (по дефолту имя переменной ограничено 17 символами, имхо - мало)


Итог. Я считаю, что примение тулзы не оправдывает интеграции её в CI-процесс. Достаточно периодических инспекций вручную, раз за итерацию.

Вот рулы которые часто оказываются полезными в нашем текущем проекте:

AvoidConstantsInterface - этот антипаттерн наши разработчики повторяют с завидной регулярностью
ConstructorCallsOverridableMethod - это правило я начал особенно ценить после того, как потратил много времени на поиск багов, вызванных его несоблюдением
PreserveStackTrace - это правило заботливо следит, чтобы не терялись stack trace родных исключений при замене их собственными. Его соблюдение помогает при анализе ошибок от customer'а, когда доступны только логи.
MethodReturnsInternalArray - на баги от несоблюдения этого правила я еще не натыкался, но тем не менее считаю его достаточно важным, такие ошибки не так просто отловить.

Эти правила после некоторого опыта использования мы убрали:

Правило DoubleCheckedLocking уже не актуально с введением новой модели памяти в Java, так что его я бы не рекомендовал.
ConfusingTernary и CyclomaticComplexity на первый взгляд должны бы улучшать читаемость. На практике после фикса ситуация не слишком меняется, а в отдельных случаях код еще больше запутывается.

спасибо за ответы.



Т.е. не находите полезными эти показатели? По сути, чем быстрее найдем ошибки, тем дешевле исправлять. Без CI такое провернуть сложно, ибо будут забивать/забывать делать инспекции в ручную. 

powerOn, это все-таки не ошибки, это недочеты. Цена их неисправления = вероятность перехода недочета в ошибку * стоимость исправления ошибки. И вот этот показатель невелик.

Я не призываю никого отказываться от сбора метрик, но практическая ценность конкретно в моем случае была совсем невелика. Разве что стиль у некоторых разработчиков чуть улучшился.

...Ну а забивать, как известно, можно и с CI 

batigoal, понятно.

Вопрос еще в догонку, а может кто-нибудь знает открытый проект, у которого прогон PMD дает очень мало ворнингов? Понятно, что не на всем наборе рулов, по крайней мере на его большей части.

У самого PMD прогон дает относительно немного предупреждений.
Также весьма неплохо выглядит DBUnit

Я тоже везде Sonar использую. Правила практически никакие не отключаю, качество текущего проекта близко к 100%. Это все возможно, и это все важно