ABAP Code Metrics

If you're an #SAP customer, most probably you have developed over the time your #custom_code. Maybe it's not much, and maybe there's a lot of it. But how to quantify your custom #ABAP code?

There are many ways to quantify the code or it's characteristics. One of them is the number of lines, statements, and comments. Since in SAP everything is open, one could easily access the source codes on DB level and count the number of lines.

But we, programers, have the reputation of being lazy. So yes, why should I develop something new, when I can use the existing logic?!

Most probably many of you know the transaction #/SDF/CD_CCA (or one of its copies -- #CCAPPS and #CC_APPS; dear #Simplification in #S/4HANA, please don't blame it on SAP developers!). There, on the initial screen, you can navigate to #Code_Metric, where you can use some filter criteria or turn on additional analysis modes.

With the basic modes we get four measurements -- lines of code, number of statements, number of comments, and number of pseudocomments/pragmas.

But how reliable are these metrics? I used them now and then to get a feeling how much code is there -- a company in waste and recycle sector with over 5 millions lines of code, an add-on developer with over 1 million lines of code, … BTW:-- what are the most blown up systems you worked with?

So I thought -- let's just try it out with very simple units!

Global classes

A newly created class, although it has some code, will not be recognized and counted as code. It is, because there is no executable code -- the complete definition section and the statements CLASS … IMPLEMENTATION and ENDCLASS from the implementation section are not counted.

Any comments, pragmas, and pseudocomments in the definition section won't be counted either. But the statements METHOD and ENDMETHOD from class implementation will get counted.

Any includes in the methods implementation won't be expanded, so their code won't be counted. And if the content of the include is not encapsulated in a procedure, it won't be counted either.

A global class can contain also class specific includes. These will be counted partially.

- Class-relevant Local Types can contain only definitions, so it won't be counted.

- Local Types can be used not only for definitions, but also for implementation of local helper classes; this local classes will be handled like global classes, so only methods implementation will be counted.

- Test Classes can contain classes, but their code won't be counted; however, if the test classes are put into Local Types include, the code of their methods implementation will be counted again.

- Macros can contain executable code, but won't be counted, and the macros themselfes won't be expanded (just like includes). But if the macro is defined inside a method, then it will be counted again, since then its code is encapsulated in a method implementation; but then it would be only possible to use it from inside the following methods.

Summary (for global classes)

The provided metrics are quite reliable for global classes -- definition part and content of Test Classes include won't be counted, both being reasonable. That the content of Macros include won't be counted is however not really understandable for me.

Function groups

By a newly created function group the metrics are same as by global classes -- there is no executable code, so the program will not be recognized and counted as code.

By function modules everything between FUNCTION and ENDFUNCTION, including these statements, will be counted. But no comments or empty lines before FUNCTION or after ENDFUNCTION. The only exception are subroutines implemented in function module include. I personally think, it's not a good idea -- each function group has its own include for subroutines, so why would anyone put them in the function module include? If you need an example, see SAP standard function module TRINT_COMPLETE_REQUEST.

Also a function group can contain local classes, but just like by global classes -- only the methods implementation will be counted. Local classes from T99 include (test classes) won't however be counted, even if they're not defined as test classes. Test classes from other includes will be counted. A local class definition / implementation could even be put into function module include, then it will be counted, just like the subroutines. Subroutines are counted with all statements between FORM and ENDFORM, including them both.

Neither reporting and selection screen events, nor (selection) screens will be counted. But output and input modules though. Just like by classes, macros won't be counted either, unless they're defined in one of the other procedures. Includes won't be expanded.

Summary (for function groups)

The provided metrics are quite reliable for function groups -- diverse definitions and content of Test Classes include won't be counted, both being reasonable. That the macros won't be counted is however not really understandable for me, and that the code of reporting and selection screen events won't be counted, results probably from the counting logic, which considers only the content of the procedures.

Reports

By reports counting starts with the initial statement -- REPORT in this case. Header comment will not be counted, unless it's shifted below the line with REPORT statement, which however, is not the default position. Code will be counted only to the last executable statement, any empty lines or comments afterwards won't be counted, even if later on any procedures are implemented. Macros are counted as they are, not as included on the calling line. So if they're used multiple times, their code will be counted only once. Includes won't be expanded.

Unlike by function groups, reporting and selection screen events and selection screen definitions (but not the logic for screens) will also be counted, both the content and the introductory statements. Another difference is handling of includes -- by reports procedures from includes will also be counted, which was not the case by classes and function groups (except for includes that logically belong to the function group, named by the scheme L[function_group_name]+++). This means however, that these procedures will be counted mutliple times, when e.g. counting for all repository objects from a package is executed. But any free-floating statements from includes don't get counted, only the procedures.

However, statements not belonging to procedures will only be counted if they're in the same include (or master program) as the introductory statement REPORT. By larger reports usually a TOP include is used, in which only definitions should be done, but the introductory statement should also be put there. In this way any other statements from the master program, which don't belong to a procedure, won't be counted.

Since there is no dedicated include for test classes by reports, these will always be counted.

By the way:-- in the above screenshot, the number of statements in report is 11, This is from line 6 to line 19 minus the method implementation. However, if the include would be placed after the implementation of class ltc_1, there would be only 9 lines counted for the report.

Summary (for reports)

The provided metrics are not reliable for reports -- which statements will be counted depends on how the program is divided and in which part the introductory statement is placed. Since procedures from includes will also be calculated, they could be calculated multiple times. It seems there is no way to exclude test classes by the counting.

Implicit enhancements

The code of the implicit enhancements won't be counted. Most probably, because the tool is restricted to only four program types.

Summary

The Code Metric provided by SAP is in most cases reliable, at least by the basic variant; maybe it's questionable, why definitions and comments outside of procedures are not counted, but that's the way it is.

To make sure that the logic of reporting and selection screen events and enhancements will be counted, it should be implemented in a method of a local or global class; the code in an event or enhancement should contain only one method call.

Counting lines by reports is less reliable, but if all the logic of the report will be implemented in methods of local or global classes, and the selection screens and events will be defined in different include then the introductory statement REPORT, then it will work.

To get the best results, adhere to the conventions given by SAP -- test classes in appropriate includes and function group includes named after the scheme L[function_group_name]+++. However, if you want that all the documention will be counted, you shouldn't adhere to the given conventions -- header comments for reports, and procedures should be placed after the introductory statement.

It seems that two problems can't be solved -- test classes in reports will always be counted, and macros outside of procedures and master programs will never be counted.

I hope you enjoyed reading this article and now know better, how the code gets counted. Which metrics do you use, to quantify and qualify your code?

#know_your_abap