SAP delivers several metrics checks for the Code Inspector. These are for example
- Number of Executable Statements
- Procedural Metrics with Statements check
- OO Size Metrics (number of methods, attributes …)
From my point of view checks which are counting statements have the problem, that they do not say very much about the compliance of the coding with different principles like Single Responsibility Principle or the Separation of Concerns Principle described by Clean Code Development. For example, think about a function in which you call ten functions. A statement count would only recognize the ten CALL FUNCTION statements which would be ok, in case you have defined a limit of ten statements in the statement count check. But what about the purpose of that? Makes it sense to really call that ten functions from a maintenance point of view or would it make sense to structure the coding, that the functionality is more reusable? Another gap of the statement count is also, that you can define big interfaces in functions or methods which would also not be recognized. So if you define a function with 100 parameters and call it in another function the statement check would be ok, but from a clean code development perspective it is terrible.
So from my point of view a check for Lines of Code is more useful in most cases. Violations of defined Lines of Code metrics give some hints about the violations of Clean Code Development principles (e.g. Separation of Concerns). In some projects I have third party check tools which are able to check Lines of Code on processing block level. But in some projects I do not have these tools or are not allowed to use them. Therefore I decided to make a little Code Inspector check implementation which does the check for us. Our main goal was to check the length of methods and functions, therefore in the first version the check supports only these two kinds of objects.
Lines of Code check explained from a user point of view
The implemented Lines of Code check is available under the standard Code Inspector check category “Metrics and Statistics” if you define a Code Inspector check variant.
The check has following attributes which allow configure the check.
The attributes have following meaning and can be configured separate for methods and functions:
- Message if more than …: Here the number of lines can be defined which are ok for the object. An message is just reported if the object has more lines than the defined ones. In case no number is defined the check for the specific object is not executed.
- Message Level: This attribute defines if the message should be reported as Error, Warning or Information/Note.
- E = Error
- W = Warning
- N = Information/Note
- Count start/end statement: Defines if the start and end statement is also counted (e.g. for a function the lines with FUNCTION and ENDFUNCTION would also be considered).
- Count empty lines: Defines if empty lines are counted.
- Count comments: Defines if comment lines are counted (lines beginning with a star or lines which do only have a comment started with an apostroph).
After an execution of an inspection with the check variant you get following messages in case of a found violation.
Of course the standard Code Inspector functions like navigation to the reported object are available here too.
How to implement the Lines of Code check and make it usable?
I do not want to describe it here how to create an own Code Inspector check from scratch, because Peter Inotai has already described it a long time ago in this blog Code Inspector – How to create a new check. I just wanna describe it, what steps you have to do, to be able to use the Lines of Code check in your environment.
- Create ABAP Class
In the SAPlink Nugget file available in repository https://github.com/pfefferf/abap_ci_lines_of_code_check the class ZZ_CL_CI_LINES_OF_CODE is available. The SAPLink nugget needs to be imported via SAPlink.
Consider that the check was written on a NW 7.40 system. Therefore some of the new ABAP syntax (e.g. table expressions, NEW constructor expression) were used. If you wanna use the code on a system with a lower release, some little changes have to be made.
- “Register” ABAP Class for Code Inspector
If you now start the Code Inspector transaction and define a new check variant you will not see the new check. To be able to see it you have to go to “Goto -> Management of -> Tests” in the Code Inspector transaction.
In the upcoming screen you should see the class you have created before. Just tick the flag in front of the class and the new check is then visible when you define a check variant.
Integration with ABAP Test Cockpit
A great advantage of the Code Inspector checks is that they are used by the ABAP Test Cockpit. So in the ABAP Workbench and in the ABAP Development Tools for Eclipse the new check can be used without further big effort. The only thing to be done is that you define the Code Inspector check variant which has to be used by the ABAP Test Cockpit runs. This can be done by
- defining your check variant as global default variant in transaction ATC.
- defining the check variant each time you execute the ABAP Test Cockpit run by “Check -> Check with ABAP Test Cockpit (ATC) with” in the ABAP workbench
- defining the check variant in the properties of an ABAP project in the ABAP Development Tools for Eclipse
So you get the results of your check directly after executing the ATC checks. Here is an result example of the new in the new ATC problems view within Eclipse.
The implemented check is a nice helper for me to have an immediate feedback about my code size. Next steps are to enhance the check so that is supports more objects (e.g. forms because of legacy reasons, whole classes, programs). If you have any comments or questions please let me know.