Skip to Content
Author's profile photo Florian Pfeffer

Lines of Code Check with Code Inspector


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.


  1. Create ABAP Class
    In the SAPlink Nugget file available in repository 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.
  2. “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.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Christian Drumm
      Christian Drumm

      Hi Florian,

      nice blog!

      I have one suggestion: maybe you could package t up the two classes as a SAPlink file.



      Author's profile photo Florian Pfeffer
      Florian Pfeffer
      Blog Post Author

      Hi Christian,

      the nugget file is attached now.

      Best regards,


      Author's profile photo Peter Inotai
      Peter Inotai

      Hi Florian,

      Very interesting blog. Similar topics was also covered in this blog: Does ABAP Really Require Longer Procedures?

      With ABAP it's a little bit tricky, but counting the lines is a simple approach and it should work in most of the cases.

      I've just installed this check in our ERP EHp7 system, but probable I'll downport it and test it a little bit to get a feeling what the right limit is.



      PS: Thanks for mentioning my blog as a reference. 😉

      Author's profile photo Former Member
      Former Member

      Hello Florian

      Thanks for this blog!

      It was really helpfull to get a better view on the code inspector.

      Kind regards


      Author's profile photo Florian Pfeffer
      Florian Pfeffer
      Blog Post Author

      You are welcome. 🙂

      Author's profile photo Sergio Ferrari
      Sergio Ferrari

      Good, I'm also interested into Code Inspector, ATC, metrics and ABAP quality.

      I'm used to run inspection using the standard check available in Metrics and Statistics - Number of Executable Statements Metrics - Show warnings - Executable statement metric - <"Warn if more than ... stmnts >.

      Am I missing something or it can also count LOC and warn in case of too long processing blocks ?

      Thank you


      Author's profile photo Florian Pfeffer
      Florian Pfeffer
      Blog Post Author

      Hello Sergio,

      thx for your feedback.

      The standard check you mentioned counts statements as the name suggests, but not Lines of Code. The result of that check would be the same than the result of the LoC check in case you have one executable statement per line.

      For example if you call a method within another method which has ten importing parameters you have ~10 lines of code (if you format it well readable 😉 ). The executable statement check would count one statement (the call method statement). The LoC check would count ten lines.

      Best regards,


      Author's profile photo Sergio Ferrari
      Sergio Ferrari

      I see, thanks.

      Author's profile photo Timo John
      Timo John

      Thanks for sharing your code.

      There is also a very helpful report available by SAP:


      this helps you to list the painpoints very fast 😥

      Author's profile photo Florian Pfeffer
      Florian Pfeffer
      Blog Post Author

      Hi Timo,

      thx. Will definitely have a look to the report when I have access to an ABAP system after my holidays.

      Best regards,