Automatic control of class structure

Each company has its own standard code design and it is important to adhere to it. The code formatters built into IDE solve this task partially, since they basically only allow achieving a simple alignment of the code. In addition, I also want order in the sequence of declaring both fields, methods, and nested classes. The reasons why the standard code does not comply with the mass: the programmer may not notice a deviation from the standard before sending the code to the repository; the new developer did not carefully read the document; in the pursuit of a hot fix, the format was forgotten; either because of the banal fatigue or laziness of the programmer; automatic refactoring and so on. Regular code review does not solve the essence of the problem, since it takes too much time and slows down the development - we need automation of the code compliance check at the time of its writing!

Frequent problems:

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

Tired of enduring this in the code?

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

The user is asked to describe the desired format of the class content (structure) using regular expression slices for fields (Field), methods (Method), constructors (Ctor), internal classes (InnerClass), the separator between class elements is "###".
When specifying the class structure in a regular expression, you can specify access modifiers, annotations, types, and names.
')

Examples of using

An example of the simplest rule: in the class, first the fields are declared, then the methods and then the inner classes:
Field(.*) ### Method(.*) ### InnerClass(.*)
Example for fields: public statics, then protekted, then annotation @Autowired, then private fields:
Field(public static final.*) ###
Field((private|protected) static final.*) ###
Field(@Autowired.* public) ###
Field(private.*)
The “. *” Template can be omitted at the end of the rule — automatically substituted.

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. Allowing this will not make even a minute, since in the Eclipse Outline window methods and fields of classes are dragged with the mouse and the required order is easily restored. Each ad located in the wrong place is highlighted by a message.

Example of a rule from real life (the format of our code):
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 hit the CheckStyle 5.2 and 5.3 release. Negotiations with the project developer were underway and he gave no explanation for what does not like this decision. Link to the patch discussion on the new check - here .

I would like to appeal to the community with a request to support CustomDeclarationOrderCheck in the comments on the SourceForge website, or write in the Habrahabr comments possible reasons for refusal and what should be improved, share the experience of promoting their developments in open projects.

Those who want to test the functionality of the module can use our builds:

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 <Eclipse PATH> / plugins.

The proposed builds include several patches of our team that were never included in CheckStyle releases:

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

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

Our team does not stop working on the development of CheckStyle. Finished patches were provided by users of solid90 , rusya7 , daniilyar , romanivanov . It would be especially pleasant for all of these to join the habrauser community.
Continuing the theme here .