Automatic class structure control

Each company has its own code format standard.and it’s important to stick with it. The code formatters built into the IDE solve this problem in part, since they basically only allow for simple alignment of the code. In addition to this, I also want order in the declaration sequence of both fields, methods, and nested classes. The reasons why the standard code is not respected are: the programmer may not notice a deviation from the standard before sending the code to the repository; The new developer did not read the document carefully enough in pursuit of a hot fix, they forgot about the format; either because of the banal tiredness or laziness of the programmer; automatic refactoring and so on. A regular review code does not solve the essence of the problem, since it takes too much time and slows down development - you need to automate code compliance verification at the time of writing!

Common problems:

• the constructor unexpectedly appears in the middle of the class;
• the inner class is declared somewhere in the middle of the outer class;
• an abstract method is declared somewhere in the middle of a large abstract class;
• The @Autowired method is also located anywhere but not in a prominent place;
• static builder methods are scattered around the class code;
• the class field was lost somewhere between the inner class and the methods.

Tired of enduring this in code?

Many of you are probably already familiar with the CheckStyle programming style checking system , which allows you to automatically check whether the Java code style matches the standard defined by the user, as well as with its Eclipse plug-in Eclipse-cs . CheckStyle is used console-based, implemented a lot of plug-ins and verification tools based on it and that is why it was taken as a basis. The above checks are partially already implemented in the Declaration Order module , which works according to the standard declared by Sun. But there is no way to customize the standard to your needs and your own style. Our development team has proposed and implemented a new test module that would satisfy anyone due to the flexibility of settings in the description of the class structure.

The user is invited to describe the desired format of the content (structure) of the class using pieces of regular expressions for fields (Field), methods (Method), constructors (Ctor), internal classes (InnerClass), the separator between class elements is “###”.
When defining a class structure in a regular expression, you can specify access modifiers, annotations, types, names.

Examples of using

An example of the simplest rule: first fields are declared in the class, then methods and then inner classes:
Field(.*) ### Method(.*) ### InnerClass(.*)
Example for fields: public of statics, then protected, then annotation @Autowired, then private fields: The ". *" Pattern can be omitted at the end of the rule - it is automatically inserted . The result of the test module is visible immediately after saving the file, which allows the developer to instantly receive information about the violation of the order. It won't take a minute to resolve this, since in the Eclipse Outline window methods and class fields are dragged by the mouse and the required order is easily restored. Each announcement located in the wrong place is highlighted with a message. An example of a rule from real life (the format of our code):
Field(public static final.*) ###
Field((private|protected) static final.*) ###
Field(@Autowired.* public) ###
Field(private.*)





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(.*)


Support needed

Unfortunately, this module did not make it to the CheckStyle 5.2 and 5.3 release. Negotiations with the project developer were conducted and he did not give an explanation why he did not like such a solution. Link to the patch discussion on the new check - here .

I would like to ask the community to support CustomDeclarationOrderCheck in the comments on the SourceForge website, or write possible reasons for the refusal in the comments of Habrahabr and what it’s worth to refine, share the experience of promoting your developments in open projects.

Those who want to check the functionality of the module can use our assemblies:

1. Eclipse-cs 5.3 ;
2. Eclipse-cs 5.2 ;
3. Eclipse-cs 5.1 .

To do this, you need to download the archive for Eclipse-cs ( update site ) of your version and copy the contents of the net.sf.eclipsecs.checkstyle_x.xxxxx ... x folder from the archive with the replacement of the proposed files in/ plugins.

In the proposed builds, several patches of our team are included, which were not included in the CheckStyle releases:

1. Update for Maximum Line Length check ;
2. New check: CustomDeclarationOrderCheck ;
3. MultipleVariableDeclarations fixes .

After you have installed the checkstyle plugin and installed a patch on it with our additional modules, in
Window -> Preferences -> Checkstyle you create, edit the Check Configuration ( New , Configure ).
In the configuration window that appears, you need to go into the group of Coding problems modules and create a new Custom Declaration Order Check module from the list .

Our team does not stop working on the development of CheckStyle. Ready-made patches were provided by users of solid90 , rusya7 , daniilyar , romanivanov. All of the above would be especially nice to join the community of habrayuzer.
Continuation of the topic here .