Pull to refresh

Автоматический контроль структуры класса

Java *
Sandbox
imageУ каждой компании есть свой стандарт оформления кода и важно придерживаться его. Встроенные в IDE форматеры кода решают это задачу частично, так как они в основном позволяют лишь добиться простого выравнивая кода. Помимо этого хочется еще и порядка в последовательности объявления как полей, методов, так и вложенных классов. Причин, по которым код-стандарт не соблюдается масса: программист перед отправкой кода в репозиторий может не заметить отклонение от стандарта; новый разработчик недостаточно внимательно прочитал документ; в погоне за хот фиксом о формате забыли; либо из-за банальной усталости или лени программиста; автоматического рефакторинга и так далее. Регулярный код-ревью не решает суть проблемы, так как занимает слишком много времени и тормозит разработку — нужна автоматизация проверки соответствия кода в момент его написания!

Частые проблемы:
  • конструктор неожиданно появляется в середине класса;
  • внутренний класс объявлен где-то в середине внешнего класса;
  • абстрактный метод объявлен где-то в середине большого абстрактного класса;
  • @Autowired метод тоже расположен где угодно но только не на самом видном месте;
  • статические билдер методы разбросаны по коду класса;
  • поле класса затерялось где-то между внутренним классом и методами.

Надоело такое терпеть в коде?

Многие из вас наверное уже знакомы с системой проверки стиля программирования CheckStyle, позволяющая автоматически проверять соответствие стиля Java кода к стандарту, определенным пользователем, а также с ее Eclipse плагином Eclipse-cs. CheckStyle используется консольно, реализовано множество плагинов и средств проверки на его основе и именно поэтому он был взят за основу. Вышеописанные проверки частично уже реализованы в модуле Declaration Order, работающему по стандарту, который был заявлен Sun. Но в нем нет возможности настроить стандарт под свои нужны и свой стиль. Наша группа разработчиков предложила и реализовала новый проверочный модуль, который бы удовлетворил любого за счет гибкости настроек в описании структуры класса.

Пользователю предлагается описать желаемый формат содержимого(структуры) класса с помощью кусочков регулярных выражений для полей(Field), методов(Method), конструкторов(Ctor), внутренних класов(InnerClass), разделитель между элементами класса — «###».
При задании структуры класса в регулярном выражении можно указывать модификаторы доступа, аннотации, типы, имена.

Примеры использования


Пример простейшего правила: в классе объявлены сначала поля, потом методы и потом внутренние классы:
Field(.*) ### Method(.*) ### InnerClass(.*)
Пример для полей: паблик статики, потом протектед, потом аннотирование @Autowired, потом приватные поля:
Field(public static final.*) ###
Field((private|protected) static final.*) ###
Field(@Autowired.* public) ###
Field(private.*)

Шаблон «.*» можно не указывать в конце правила — подставляется автоматически.

imageРезультат работы проверочного модуля виден сразу после сохранения файла, что позволяет разработчику мгновенно получать информацию о нарушении порядка. Разрешить это не составит и минуты, благо в Outline окне Eclipse методы и поля классов перетаскиваются мышкой и требуемый порядок легко восстанавливается. Каждое объявление расположенное в неправильном месте подсвечивается сообщением.

Пример правила из реальной жизни (формат нашего кода):
Field(private static final long serialVersionUID) ### Field((private|protected) final Log ([\w]*L|l)og|private static final Log [\w]*LOG) ### Field(public static final) ### Field((private|protected) static final) ### Field(@Autowired.* public) ### Field(public.*) ### Field(public) ### Field(private final) ### Field(private.*) ### Field(private) ### Field(.*) ### Method(public static void main.*) ### Method((public|protected)?\w*abstract) ### Method(public static .*(new|edit|create|open|clone).*) ### Ctor(public) ### Ctor(private) ### Method(@Autowired.* public) ### Method(.*) ### InnerClass(.*)

Необходима поддержка


К сожалению, данный модуль так и не попал в релиз CheckStyle 5.2 и 5.3. Переговоры с разработчиком проекта велись и он не дал объяснений чем не нравится подобное решение. Ссылка на патч обсуждение по новому чеку — тут.

Хотелось бы обратится к сообществу с просьбой поддержать CustomDeclarationOrderCheck в комментриях на SourceForge сайте, или написать в комментариях Хабрахабра возможные причины отказа и что стоит доработать, поделиться опытом продвижения своих наработок в открытые проекты.

Желающие проверить работоспособность модуля, могут воспользоваться нашими сборками:
  1. Eclipse-cs 5.3;
  2. Eclipse-cs 5.2;
  3. Eclipse-cs 5.1.

Для этого вам необходимо скачать архив для Eclipse-cs (update site) вашей версии и скопировать содержимое папки net.sf.eclipsecs.checkstyle_x.x.x.xxx...x из архива с заменой предлагаемых файлов в <Eclipse PATH>/plugins.

В предложенных сборках включены несколько патчей нашей команды, которые так и не были включены в релизы CheckStyle:
  1. Update for Maximum Line Length check;
  2. New check: CustomDeclarationOrderCheck;
  3. MultipleVariableDeclarations fixes.

После того, как вы установили себе плагин checkstyle и поставили на него патч с нашими дополнительными модулями, в
Window -> Preferences -> Checkstyle вы создаете, редактируете Check Configuration (New, Configure).
В появившемся окне конфигурации вам надо зайти в группу модулей Coding problems и создать из списка новый модуль Custom Declaration Order Check.

Наша команда не прекращает работу по развитию CheckStyle. Готовые патчи были предоставлены пользователями solid90, rusya7, daniilyar, romanivanov. Всем перечисленным было бы особо приятно присоединится к сообществу хабраюзеров.
Продолжение темы тут.
Tags: javacoding stylecheckstylestructureopen sourceструктура класса
Hubs: Java
Total votes 28: ↑23 and ↓5 +18
Comments 29
Comments Comments 29

Popular right now