Automatic quality control of Java code

The code that the programmer writes must be working - the very first rule of successful work, with which the programmer himself and all his superiors will agree. But, in addition, the code should just work, often with increased requirements - the presence of comments (internal documentation), readability, speed of change, compatibility with explicit and implicit standards. All that can be called quality code.

However, unlike code health, which can be assessed by performing verification tests, the quality of the code is not a simple TRUE or FALSE assessment. Moreover, the quality of a code is understood as a set of subjective assessments of the perception of a code by another person. However, let's still try to somehow formalize the quality assessment task, and, if possible, provide a way to automatically accomplish this task.

What can be at least an initial list of items for evaluation?

Compiling the whole code
Efficiency of the whole code
Compliance with the style of writing code used in the project
Availability of documentation for each section of code
Readability of the code at the level of individual lines, functions, files
The ability to quickly make changes to the code, affecting the minimum existing functionality

Compilation

Unfortunately, there are still situations in our life when the code on the project is not compiled entirely. In the code tree there are sections written a few years ago that nobody touched, nobody changed, and they somehow somehow stopped not only working, but even compiling themselves. At the same time, these sections of the code are not used in 99%, 99.9% or even 99.98% of cases, but when X comes (and according to Murphy's law, it will definitely come in the production system), the customer will be very distressed.
')
Is it possible to deal with this? Need to! Manually - full periodic compilation of all the code in the project, and better automatically. For example, set up a weekly compilation of code, and better at the same time putting this code on a so-called “integration server” - which will contain the most recent, possibly inoperative code. But on this server you will always have the current status of your project, and certainly do not miss the compilation errors.

A separate line worth mentioning the compilation of non-java files. For almost any scripts, and for JSP pages, there is a way to check the file for compilation errors. For example, in WebLogic, you can specify the precompile parameter for your web application. If any JSP contains errors, the precompilation is interrupted and displays an error in the log. There is also a jspc utility, part of WebLogic, that performs the same function for individual jsp.

Performance

Does your code work? And how do you know? Can you tell if the whole code is working right now, or did some part work exactly two weeks ago, and now it may not work anymore? But you know yourself that almost any change can “break” something not where it should be, and even where it is not necessary.

Or is your confidence based on the QA (quality assurance) department putting “passed” on all your bugs / issues / patches? So it still means nothing! First, in some companies, QA only tests changed parts of the system. Secondly, QA is lazy and unprofessional, and, as shown by my recent experience in some unnamed company, it may just put passed to the test, which was just too lazy to pass. Thirdly, most likely people work in QA too, and they too can make mistakes.

Therefore, to assess the performance of automated tests are already everywhere. They allow you to assess whether your code is operational or not at 100%. True, for this you need to:

automatic tests were
These automated tests should cover 100% of the functionality.

If the first item is an organizational task, then the second is a technical one. And by “100%” you need to understand not the existence of a test for each requirement in certain requirements, but the fact that each line of code will be executed as a result of executing at least one test. This characteristic is called “ code coverage ” and literally means the degree of code coverage by tests. The following indicators are distinguished:

Function Coverage - method call counting
Decision Coverage - counting by possible directions of code execution (then-else or case-case-default in control structures). It takes into account the only branch in each case.
Statement Coverage - counting on specific lines of code
Path Coverage - counting by possible code execution paths. A broader concept than decision coverage, as it takes into account the result of all branches.
Conditional Coverage - the calculation of the possible results of the calculation of the values of Boolean expressions and subexpressions in the code.

Some indicators are purely theoretical and are usually not used for practical applications, for example, “Path Coverage”. Since the achievement of this indicator to 100% for any cycle with a variable number of iterations will mean the need to check for all possible number of iterations ... and if it depends on the user? Yes, it is almost impossible to check. Therefore, either “functional coverage” or “statement coverage” is usually used (it is easy to get decision coverage from the latter). From open source projects can be noted:

emma.sourceforge.net - EMMA
cobertura.sourceforge.net - Cobertura

EclEmma - Java Code Coverage for Eclipse

Style

The code should be easy to read, not convenient to write.
Steve McConnell, SD West '04
(the author does not quite agree with this statement,
but cites it as an authoritative opinion of authority)

Well, suppose your code works. I also want him to be understandable. For this, many techniques and rules are used, and the very first thing is compliance of the code design with a certain style. For example, our company uses the following style: " Sun Java Conventions + {} on new line". I would like to thank the authors of such an understandable concept. Because in my IDE it is enough for me to take the “Java Conventions” design rules, copy them into new ones, and change only one (ok, five to be honest) setup.

Why just about IDE? Yes, because the style of the code must be supported not by the programmer, but by his IDE, and the programmer only has to ensure that the program does not bury. But if the program was wrong, but the programmer did not trace? Then again, automatic verification tools come to the rescue:

checkstyle.sourceforge.net - Checkstyle

But the style does not end with the design and the number of spaces in the indent. The next step is the use of generally accepted or corporate standards in the code. For example, it is assumed that any Serializable class must have a serialVersionUID, that any Exception must be immutable , and the value of the exception in the catch block does not change. And although a violation of these agreements may not create errors at the moment, they make the code worse understood by the person who expects to follow standard rules. Among the programs that check the code for such inconsistencies, I would like to mention the same checkstyle, as well as the FindBugs program:

findbugs.sourceforge.net - FindBugs

This area of code verification is called static analysis . This includes both simple checks, for example, the presence of a serialVersionUID in the Serializable class, and more complex, such as unclosed input / output I / O streams. Again, these utilities can find errors in the code that seems to pass 100% of the tests and has 100% Coverage. Simply then these utilities will find potential errors and inconsistencies of the program with the standard programming style.

Using FindBugs in Eclipse

Partially statistical analysis can also be performed by IDE (Eclipse - during compilation, IDEA - “Code Inspections”). Utilities are divided into two groups - those that work with the source code (the majority), and those that already work with compiled files. It is worth noting that FindBugs works with compiled code, that is, your boss and your customer can conduct a check ... I think it’s best to take care of a good result (emoticon).

Documentation

How many words are said about the need for documentation for the code ... I’ll dwell only on the fact that modern IDEs allow you to automatically underline those parts of the code where there is no javadoc comment, check the correctness of its design, the presence of all necessary tags ( @since , @since , @author , etc). Look in the settings and be sure to turn it on at least for public methods and classes (and better for protected).

There are also special programs that allow you to analyze the code for the presence of JavaDoc comments. For example, the already mentioned CheckStyle.
Of course, this will not replace a couple of pages of documentation from the developer with plain text with a couple of drawings, in which he would explain where the entry, exit points are in the code, and draw at least an approximate path between them.

Readability code

Of course, so far even Microsoft Word (OpenOffice Writer) cannot distinguish a good text from a bad text. Maximum - correct grammatical and stylistic errors. But at least something.

Therefore, it is also difficult for the code to formalize the concept of “readability”, but there are some characteristics that mark readable code from unreadable:

individual line size not more than 120 characters to fit on the screen
the size of the method is no more than one screen, so that the reader can cover the whole method with a look and understand what he is doing
class size is not more than 1000 lines - lack of anti-blot blob
the absence of "magic" constants (for example, 5, 7, 10 ... the reader should easily understand what these numbers are and where they come from)

Most of these checks relate to the style of the code, and are checked already called utilities.

Summing up the "results"

What do you need to do to have the utilities automatically help you monitor the quality of the code?

If you do not have a version control system, then you should start it. Although, I hope, you still have it, otherwise why this whole article?
If the company has certain rules (patterns) of writing code, restrictions, they should be formalized, and, if possible, described in a language that is understandable to one of the automatic utilities.
Set up a dedicated server (integration), which every night will take all the code from the current HEAD / Stream, compile it and “upload” it to the server. The server should preferably be run in -ea mode (enable assertions), at least for the code you wrote.
During the compilation process, the code should be checked by utilities that work with the source code (for example, Checkstyle), and then by utilities that work with byte-code (for example, FindBugs)
The result of the compilation, especially if there are errors, send to the mail
After rebooting the server, run a series of automatic tests on it.
When executing tests, it would be nice to connect utilities to evaluate coverage, as well as some internal performance statistics. The results can be stored in the database, and after a while you can accumulate good indicators of how you improve, speed up or slow down the code during the development process.

Coming in the morning, the programmer should receive a task list for the day from the task server, and the current status of the code from the integration server.