Automatic quality check of Java code (iteration 1)

I am planning this series of articles, like a story in several parts about how to configure the automatic code quality check in our project. This process, seemingly simple, turned out to be full of unobvious details, so there was a desire to clarify the difficulties and their solutions to a wide audience, so that everyone could make their code a little better by circumventing more rake.

In the end, I want to ensure that inspections, style checking, and metrics calculation are run on the assembly server, then everyone will know what the state of the project is. And, ideally, all those checks that are triggered on the server should also work in the IDE, so that comments to your code can be eliminated before the whole team knows about them. As approaches improve, iterations will be added and published.

In this iteration, I will configure inspection checks. The whole team uses JetBrains' IntelliJ IDEA and TeamCity , so you can use the tools they provide. To begin with, the profile of inspections will be configured in IntelliJ IDEA, the conformity of the code to which will be checked during each build using TeamCity. The method is regular and is described in the official knowledge base on TeamCity , but not everything worked out very smoothly ...

First you need to decide what to check, for this we will run IntelliJ IDEA, open the project and find the Settings (Settings). Now let's move to the Inspections section, for which it is convenient to use the search. As a result, you will see such a picture - a complete list of inspections, divided into groups (inspections are highlighted in blue, the settings of which differ from the standard ones):
')


There is a big field for creativity: each inspection can be compared with the seriousness with which it will be evaluated. Simply turning on all inspections will not force you to write code perfectly without turning on the brain. Inspections will only make you smell bad before. So there are absolutely opposite inspections, for example, "Constant on left side of comparison" and "Constant on right side of comparison". The choice here depends on your preferences and on the standards you intend to maintain. There are really a lot of inspections, a full pass will take several hours, so do not forget to stock up on good tea.

Of the useful noteworthy inspections:

• I / O resource opened but not safely closed - allows you to check that all open resources are called close and, moreover, in the right place (similar to JDBC, JNDI and nio);
• Missing Override annotation - I was hard-pressed to be treated as an error, because it is fraught with these very errors (it is not for nothing that Scala uses a mandatory keyword for such a declaration);
• Iteration over 'keySet ()' may be replaced with 'entrySet ()' iteration - oddly enough, few people think that the second method is faster and generally exists;
• Chain of 'instanceof' checks - allows you to hint malicious violators of the LSP , that you can live differently ;
• Overly long method , Class with too many methods - allows you to monitor that methods and classes are broken on time and placed on a reasonable number of screens.

When the required set of inspections is selected, it is best to assign your own name and you can export it by pressing the Export button, the rightmost one in the top row. Next, select the place where to save the xml-file with the profile. I saved the file immediately to the project folder in order to upload it to the version control system and use it further when setting up TeamCity.

You can import the saved profile to other team members via the Import option so that the checks work equally for the whole team. However, with each profile change, the team will have to re-import, because the changes to the exported file are not automatically tracked.

So, we have proceeded to configure TeamCity. TeamCity allows you to build a project in many different ways. For different methods are used so-called. Runners: Maven, Ant and about a dozen more. Among them there is a special - Inspections Runner. In order to use it, you must create a separate configuration of the assembly (Configuration) or add a step (Build step) to the existing one. The figure below shows the completed form for this step:



We have a Maven project , and for me it was a surprise to find: “The specified path should not be relative to the checkout directory. Should the project directory for directory-based (.idea) projects. Reference project. ”, The benefit of the documentation on this is clear:“ For the Maven2 project: path to the pom. xml file. ". We are collecting one of the modules ( tinkoff-portal-web ) of the multi - module Maven project , so we specify the path to the pom-file in it. Working Directory, respectively, also need to be corrected.

Another interesting point: memory consumption. Without increasing the standard maximum allocated memory size and the size of the Permanent Generation, inspection checks will fall. In the new versions of TeamCity, for example, in the 6.5.6 installed in our JVM command line parameters field, the following is written in advance:

-Xmx512m -XX:MaxPermSize=150m 

In the same field, you can force TeamCity to check or not to check certain packages , for example, it is not very interesting to see what claims there are to stubs generated for working with web services , so we only look at the classes that we wrote (for Maven, apparently, the path is indicated relative to the root of the module being tested):

 -Didea.include.patterns=src/main/java/ru/tcsbank/portal/* 

The next item is the path to our xml file with the inspection profile. Since the path must be specified relative to the root, and the project can be collected on different agents and, accordingly, in different folders. In theory, you can put the file with the profile on the build server in a separate sacred place, but then it will be extremely difficult to change it (which, by the way, may even be reasonable from some side), I also wanted to be able to quickly correct the checks performed. By experimenting and outputting to the log all the appropriate parameters for the environment, a recipe was found:

 %system.teamcity.build.checkoutDir%/tcsInspectionsProfile.xml 

Now it remains to specify only the name of the profile that we set while saving to IDEA and the number of warnings and errors that we consider to be fatal - under which the project ceases to be collected.
Initially, I took the amount a little more than the total number of failed checks, then, as the quality of the code improved, this number decreased and continues to decrease.

So, we run our build and see something like this:

Well, now we always know whether the commit has improved the quality of the code or degraded it.

In conclusion, I would like to say that TeamCity is more likely to build IntelliJ IDEA projects than Maven, it has a number of limitations: code styles are not checked, in addition to Maven, an IDEA instance is loaded on the server (when building, it runs the string “Starting up IntelliJ IDEA 10.5.2 ... ") And more ... Inspection Runner behaves strangely on some types of inspections, for example, there was a case when Unused import considered the class that was used to create an anonymous heir to be unused. Such inspections, unfortunately, had to be turned off so as not to compromise the correctness of the inspection.

Subsequent selection of inspections can be carried out with the Pizza-Driven-Development team :)

In the next iteration, I plan to try using the “IntelliJ IDEA Project” runner, there is hope that this will allow the assembly to go faster and fix problems with the accuracy of inspections and allow us to abandon the permanent reimport'ov profile inspections.