What elements need to be provided for an analysis?

The Cockpit analyzes projects based on statistical analysis techniques. To do this, a number of elements must be provided at the start of a new analysis.

There are three categories of elements:

• Source files (*.cs and *.java)
• Files generated from compiling (*.dll and *.jar)
• Libraries referenced by the project (*.dll and *.jar)

The source files are used in the analysis to calculate some metrics, such as the number of lines of code, the search for practice anomalies, and the search for duplicates. These files are also used to generate the viewable source code you can access from an anomaly in the Cockpit.

The files generated from compiling are used to extract structural elements from the code (classes, interfaces, methods, etc.), which are used to aggregate the quality measurements. Also, other metrics (number of instructions, cyclomatic complexity, etc) and practice anomalies will be extracted from these files.

Finally, the libraries are not directly analyzed, but they are useful when researching practice anomalies.

Let's consider the example of NeverMakeCtorCallOverridableMethod, which checks for calls to a virtual method in the constructor. For each method called in a constructor, this rule will check if it is virtual. If the method is defined in a library, the declaration must be accessible.

Why do we need both the source files and the compiled files in order to extract the same type of information?

In short, the source files allow us to analyze at a syntactic level. Binary files, however, provide access to the structure of the code, the chain of method calls, dependencies, and the instructions (MSIL/CIL for C# or bytecode for Java). This combination provides us with more thorough and complementary results in the Cockpit.

Finally, for consistent results, all of the elements should be synchronous. The source files should be the ones used to generate the compiled files, and the libraries should be the same versions as used in the code. To avoid problems and facilitate processes, we provide packaging tools that interface with the standard tools (MSBuild, Team Foundation System, Ant, Maven, Hudson...). They will be discussed later.

[Case study] New development on an existing application.

When starting new developments on an existing application, we often set a strategy for ourselves to improve the quality as compared to what was done before.

For this, we:

• Carry out targeted corrective actions on the existing code, actions that are quick to implement, whose benefits are concrete, and that will not increase the non-regression testing effort.
• Start with more ambitious quality objectives for the new code so that we do not reproduce existing problems and so that we do better from the start in order to avoid problems rather than correct problems.

It is difficult, however, to balance these two approaches, since traditional code quality tools analyze the entire project without differentiating between existing code and new code. As a result, when applying the desired rules, the tools generate a huge volume of alerts for the existing code. They drown the team in information, making it difficult to use. Consequently, the quality objective loses steam and is eventually limited to a few rules to be applied on the new and old development.

The Cockpit allows a different approach by keeping only the existing problems we want to correct in its radar to be sure that progress is made, while holding new development to stricter requirements.

This approach is quick and easy to implement in just 4 steps:

1. Perform a quality diagnostic on the application. This diagnostic provides a clear view of the situation by using an automatic analysis of the code and returning qualitative and quantitative information on the problems it finds.
2. Target the improvements to be made. Based on the diagnostic, you must decide which problems to solve and then prioritize them to follow the project constraints. The results of analyses performed with the Cockpit show that there are mainly critical problems corresponding to bugs that have been corrected (concurrent access problems, incorrect instructions, etc.) Other problems may be structural (non-maintainable code), excessive copy/paste code left too long and needing to be correct, or even problems with a major regression risk.
3. Clear the quality radar of problems that will not be corrected right now. With the Cockpit, quality rules can be disabled only for specific portions of code (method(s), class(es), module(s), etc.) so as to skip existing code. Reset mode also makes detected problems disappear in a given version by only considering newly detected problems. For example, it no longer detects overly complex methods that cannot be changed, but it detects all new overly complex methods.
4. Share this view with the entire project team and monitor the implementation of the process. Make it standard usage to visit the Cockpit and dashboards to control quality throughout the project.

During the next iteration, we configure Cockpit to include other improvement actions, if necessary.

This approach was designed to meet the needs of our customers who need to control overall project quality by distinguishing new development and improvements to existing code. For example, the approach is used for maintenance projects that are used internally or via a TPAM.