Fascism in the code. Part two

In my previous post, my colleague tried to reveal the idea of ​​the positive influence of " fascism " in the code on the example of one of the verification modules (checks). Together with an example, our plugin assembly was provided with some extension. Our team has developed a number of new checks and simplified installation in Eclipse.

“Fascism” in the code by using the Checkstyle project ... What could be better than such an ideology? Half, and even more comments that are made during the usual review of code by programmers can be corrected (not allowed) even at the stage of writing code. The use of test modules has a huge impact on the appearance and readability, and hence the maintainability of programs. There are a lot of books in which authors share experiences on how not to write code and show the most popular errors. All self-respecting programmers read such books as “Effective Java” by J.Bloch, “Java Puzzlers” by J.Bloch, Java Pitfalls and .... But do you use all the tips from them? As practice shows, even serious programmers make banal mistakes.

After the first release, we decided to simplify the process of using our developments. The solution was to organize your project with checks, not released in Checkstyle, in the form of an add-on (feature) to the Checkstyle plugin for Eclipse. The simplified installation process came down to:

1. We install the plugin Checkstyle plugin (update-site: eclipse-cs.sourceforge.net/update ), if it is not yet worth it.
2. We put our addition (update-site: sevntu-checkstyle.github.com/sevntu.checkstyle/update-site ).

We get a group with our checks in the settings of a textual one:


Figure 1 - Dialog box configuration checkers modules (checks)
')
After installing our module, it appears in the list of existing ones under the name " SevNTU checks ". Thus, without waiting for the main Checkstyle release, we can fully use our checks to automatically control the quality of Java code. Briefly describe the last of them.

Test module " ForbidAnnotationCheck " - checks for the use of annotations specified in the check configuration. For example:

@Autowired
private DataSource dataSource;

Using this check, you can prohibit @Autowired on the margins of the class, and make the programmer feel comfortable and use the setter for @Autowired .

Test module " VariableDeclarationUsageDistanceCheck " - used to check the distance between the definition of a variable and its first use. If the distance exceeds a certain, initially specified value, the user is informed by a message. The check is made for the case when the definition of the variable and its use are in the same scope. Includes the following options:

1. allowedDistance — sets the allowed distance between the definition of a variable and its first use.
2. ignoreVariablePattern - set a regular expression for variable names that are excluded from the check.
3. validateBetweenScopes - distance checking for the case when the definition of a variable and its use are in different scopes.
4. ignoreFinal - ignoring variables whose definition uses the keyword final .

The test module " AbbreviationAsWordInNameCheck " - checks the names of classes, interfaces, variables and methods to find abbreviations in them with capital letters. Example: “XMLReader” should be “XmlReader”. Includes the following options:

1. allowedAbbreviationLength - the resolvable number of consecutive capital letters in the abbreviation. For example: " interface ABCDInterface ". Here is the abbreviation " ABCD " and the word " Interface ". In order to ignore this case, in this option you should put the number of consecutive capital letters in the abbreviation equal to 4.
2. allowedAbbreviations - a list of abbreviations to be ignored.
3. ignoreFinal - ignoring variables whose definition uses the keyword final .
4. ignoreStatic - ignoring fields whose definition uses the static .

The " OverridableMethodInConstructorCheck " check module - checks for calling the overridden (public) public/protected methods from the constructor, the readObject and clone methods of the class. The entire call stack is checked, for example, constructor -> private method -> public/protected method .

The check module " ReturnNullInsteadOfBoolean " - is used to keep track of situations when the type of the returned object in the method declaration is Boolean , but the method itself can return null .

The test module " AvoidNotShortCircuitOperatorsForBooleanCheck " - checks conditional expressions for the use of bitwise operators ("|", "&", "| =", "& =") instead of the usual for short-circuit type operators of short-circuit logic.

Check module " AvoidConstantsInInterfacesCheck " - constants should be defined in classes (see J.Bloch "Effective Java" Item 19: Use interfaces only to define types).

The test module " AvoidHidingCauseExceptionCheck " - informs the user that he has hidden the cause of the exception. For example:

catch (IllegalStateException e) {
// your code
throw new RuntimeException();
}

This code snippet "IllegalStateException" exception.

Check module " IllegalCatchExtendedCheck " - checks the catch() blocks to catch() exceptions of the type java.lang.Exception , java.lang.Error or java.lang.RuntimeException . Includes the following options:

1. allowThrow - ignoring the catch() block if a new exception is thrown in it.
2. allowRethrow - ignoring the catch() block, if a caught exception is thrown in it.

The check module " ReturnBooleanFromTernary " - checks the branches of the ternary operator. When finding ' true ' or ' false ', as the sole content of a branch, informs the user with a message. For example, instead of the string " boolean b = a ? false : true; " it is better to use " b = !a; ".

If you consider these checks to be true truths that everyone knows - check your code and you will be surprised !!!

Who is interested in this topic, and who is interested in trying out our checks on their projects, I invite you to the project site . Wiki notes "to help the developer" here .

Thank you for attention!

PS FindBug, PMD, Sonar ... we know about the existence of these products, and some ideas were borrowed from them. But for a number of reasons, we focused our forces on Sheckstyle.