We have seen previously SONAR ‘Blockers’ for ABAP, whose name indicates that any such violation cannot be tolerated, and ‘Critical’ defects, severe enough to require immediate correction, but for which an exception can be accepted, if it is very rigourosly justified.
In our SONAR Quality Profile, ‘Blockers’ focus on anything that can stop a transaction or program and ‘Critical’ on programming practices that pose a risk to the performance.
We will conclude this series on best practices of ABAP programming with the remaining rules, which will mainly affect the maintainability of the code.
Our ABAP application is not very large: a little less than 700 files for approximately 26 000 lines, an average of 40 lines of code per program.
The level of comment is correct, above 22%. We can also see a significant percentage of duplicated code.
But this is an average that can reflect different variances and therefore very different realities. To verify this, let’s see what we have in the ‘Major’ defects.
Level of comments
The main violations of this type concern methods, classes, forms, functions, etc.. without any comment, along with a number of objects presenting an insufficient percentage of comments.
Note that there is an object oriented ABAP with classes and methods. This type of code is not very common, but you can see that SONAR can analyze it.
SONAR also lists:
- Files with a density of comments inferior to 20%.
- Objects (defined in these files) with a density less than 15%.
A program is maintainable as long as it is understandable. The longer and complicated it is, the higher the effort to introduce a change in it, but also the risk to create a default at the same time. The presence of comments in the code should allow the developer to understand more easily the logic of the program, previous evolutions or corrections and thus minimizes the maintenance costs and the risks for the stability of the application.
Duplicated code
We also have 58 programs, slightly more than 8% of the total, with duplicated code.
Duplicated code is just code that has been ‘Copy-Pasted’. A developer must implement a feature, a treatment already encoded elsewhere (usually by himself), so what could be easier than to reproduce it as many times as necessary?
This ‘bad practice’ is certainly more dangerous than insufficient documentation because any change to one of these blocks of code must be reproduced on all copies, if we don’t want that one of them ceases to function properly. This multiplies the number of all the changes to make, knowing of course that it is impossible to remember all duplications. The maintenance effort is greatly increased, and most importantly, the risk of introducing a defect becomes very high.
It is recommended to correct these violations as soon as possible, locating it – with SONAR for example – and replacing duplicated blocks with reusable functions.
Code structure
A code incorrectly structured is hard to read.
Here we have CASE treatments (for more details on this statement, see the post about the critical defects) with one or more branchs (WHEN) that count several lines of code. This means that the developer has programmed logical processing in a conditional structure. If this treatment has multiple lines (more than 4 by default for this rule), it is recommended to encapsulate it in a function that will be called by the WHEN.
SONAR identifies nested conditional processing, such as IF on 3 or more levels. To introduce a change in such a structure requires a significant effort to understand the logic, so more maintenance costs and again a higher risk of error.
The same consequences for too complex conditional expressions, with more than 4 AND or OR. Below is the sample code provided by SONAR to illustrate this rule.
Size and complexity
Other major defects that may be encountered in an ABAP application, although we have not seen so much in the code we analyzed: large programs or with too many objects.
Complexity also presents a risk to the maintainability of an application.
In fact, there is almost no object with a significant level of complexity in this application.
Conclusion
Remember that these are just a few rules of ‘Major’ type: there are many others that you can find in the Sonar Quality Profile for ABAP. We will most likely have the opportunity to examine them in the future, in connection with more articles about the ABAP world.
Project teams, SAP application managers or stakeholders often think that SONAR, because it is an Open Source software, works only with new technologies like J2EE. In fact, we have seen through this series of posts that is quick and easy to analyze ABAP code with SONAR, and implement a process – a Quality Gate for example – that can detect risks for robustness and performance while controlling maintenance costs.
This post is also available in Leer este articulo en castellano and Lire cet article en français.