У каждой компании есть свой стандарт оформления кода и важно придерживаться его. Встроенные в 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.*)Шаблон «.*» можно не указывать в конце правила — подставляется автоматически.
Результат работы проверочного модуля виден сразу после сохранения файла, что позволяет разработчику мгновенно получать информацию о нарушении порядка. Разрешить это не составит и минуты, благо в 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 сайте, или написать в комментариях Хабрахабра возможные причины отказа и что стоит доработать, поделиться опытом продвижения своих наработок в открытые проекты.
Желающие проверить работоспособность модуля, могут воспользоваться нашими сборками:
Для этого вам необходимо скачать архив для Eclipse-cs (update site) вашей версии и скопировать содержимое папки net.sf.eclipsecs.checkstyle_x.x.x.xxx...x из архива с заменой предлагаемых файлов в <Eclipse PATH>/plugins.
В предложенных сборках включены несколько патчей нашей команды, которые так и не были включены в релизы CheckStyle:
- Update for Maximum Line Length check;
- New check: CustomDeclarationOrderCheck;
- MultipleVariableDeclarations fixes.
После того, как вы установили себе плагин checkstyle и поставили на него патч с нашими дополнительными модулями, в
Window -> Preferences -> Checkstyle вы создаете, редактируете Check Configuration (New, Configure).
В появившемся окне конфигурации вам надо зайти в группу модулей Coding problems и создать из списка новый модуль Custom Declaration Order Check.
Наша команда не прекращает работу по развитию CheckStyle. Готовые патчи были предоставлены пользователями solid90, rusya7, daniilyar, romanivanov. Всем пе��ечисленным было бы особо приятно присоединится к сообществу хабраюзеров.
Продолжение темы тут.
