Skip to Content

Does ABAP Really Require Longer Procedures?

Note: I did originally publish in the following post in my company’s blog on software quality. Since it might be interesting for many ABAP developers, I re-publish it here (slightly adopted).

My colleague once summarized the benefits of short methods in his blog post: These are easier to comprehend, do better document the code (by the method name), are better to reuse and simplify testing as well as debugging or profiling. As the examples were in Java, one may intend that this will work for modern languages—but not in general, and maybe not for a language like ABAP. In this post I’ll focus if short procedures (e.g., methods, function modules, or form routines) have the same relevance for ABAP or if longer procedures are to legitimate or can not be avoided.

As an upper limit for a sub-routine’s length the post suggested 40 lines of code or the number of lines visible at once in the editor window. Sometimes even 40 lines are considered as far too long. For example, Robert C. Martin stated in his well-known book Clean Code that even 20 lines are too long and preferred micro methods with only up to five lines. Even in Java and C# development, keeping methods that short is rarely seen in practice. However, from our experience when analyzing and auditing Java or C# projects we see that most Java or C# developers agree on the advantages of having methods fitting on a screen page. Of course we’ve seen Java / C# code with a high amount of very long methods, but usually the developers are aware that this is not like it should be.

The situation is quite different when we analyze ABAP code. Of course, also here developers agree that methods and procedures in general should not become too long—but procedures with some hundred lines are more often considered as acceptable and sometimes are even preferred over short procedures. Also the official ABAP programming guidelines recommend a maximum of 150 statements and SAP’s Code Inspector will issue a warning only above this threshold with its default configuration for the procedural metrics check (see image).


SAP Code Inspector default configuration for procedural metrics

Since every statement should be placed on a single line, but may span several lines, a 100 or 150 statements long method will often be a few hundred lines long. Taking comments and empty lines into account, this number even increases.

So, does ABAP Require Longer Procedures?

Indeed, there are some reasons, that Java thresholds are not suitable for ABAP. One will note that many constructs require much more lines of code, if the code is reasonable formatted. For example, comparing a method call with three parameters in Java, e.g.

     result = calculateResult(x, y, z);

with the call to a similar function module in ABAP:



         iv_x = lv_x

         iv_y = lv_y

         iv_z = lv_z


         ev_result = lv_result.

Thus you need seven lines of ABAP code for one line of Java code. The same applies to a simple loop over a number range. In Java this are two lines (not counting the content of the loop)

     for (int i = getStart(); i <= getEnd(); i++) {

        // loop content


but ABAP requires five lines (again, without the loop content):

     DATA lv_i TYPE i.

     lv_i = get_min( ).

     WHILE lv_i <= get_max( ).

       ” loop content

       lv_i = lv_i + 1.


The latter example also shows, that variable declarations—which do not really increase the complexity—require an additional line. From these examples, one could argue that for ABAP the procedure length will be around three or four times compared to Java to achieve the same functionality.

Count Lines or Statements?

Especially when thinking about the many lines a simple function call requires in ABAP, developers often suggest to count statements instead of lines. Indeed, this would rate the function call of the first example like in Java, but still ABAP requires more statements in many cases as shown in the second example. Furthermore, consider statements like the following SELECT:

     SELECT * FROM zcqseexpobj AS z INTO TABLE deleted_objects

       WHERE z~export_config_id = me->export_meta_data-export_config_id

             AND z~object = ‘PROG’

             AND (

                     NOT EXISTS (

                             SELECT * FROM tadir AS t

                               WHERE t~pgmid = ‘R3TR’

                                     AND t~object = z~object

                                     AND t~obj_name = z~obj_name

                                     AND t~delflag <> ‘X’


                     OR NOT EXISTS (

                             SELECT * FROM reposrc AS r

                               WHERE r~progname = z~obj_name

                                     AND r~r3state = ‘A’



This is a single statement but lasts over 17 lines – and in my view it is at least as complex as 17 lines are and is not just one »simple« statement. The example is from our ABAP code extractor which we need to analyze the code—and I really would not like to have more than two of these in a single method, thus the 40 lines limit would be perfect here. As you see, statements can get very complex. That’s why we strongly prefer to count lines of code over number of statements (and it’s always clear what a line is, but not always what to count as statement). More complex procedure metrics aren’t helpful either, see e.g. Benjamin’s post on McCabe’s Cyclomatic Complexity.

Well, Let’s Count Lines—but What’s a Good Length Limit for ABAP then?

As we’ve pointed out, ABAP syntax often requires more lines in contrast to other programming languages, thus 40 lines might be a too hard limit, I agree. But 100 lines or more should be an exception if you want to keep your ABAP code maintainable. Even if you usually can express much more functionality in 40 lines of Java than in 100 lines of ABAP code. Yes, in general for Java I’d accept methods comprising more functionality than in ABAP. There are basically two reasons: First, if more lines are written, one has to read and understand more lines—thus influencing comprehensibility on its own. But the more crucial issue is the scope of local variables.

ABAP: There are No Block-Local Variables

In Java, C#, and most languages which support statement blocks, the scope of a variable defined inside a block is only from the declaration of the variable to the end of the block. For example, when defining a variable inside a loop, the variable is not accessible anymore after the loop block. This helps to lower the amount of variables which you have to consider at a certain position of your code and avoids misuse of already defined variables.

In ABAP, however, a local variable is visible from the line of its declaration till the very end of the procedure. Thus the amount of variables in your scope will always increase, even if the variable is needed only inside a specific IF, ELSE, WHILE, SELCET, or whatever block. One could reuse a variable later to store a semantically completely different value (maybe because someone is too lazy to spend an extra declaration, or one has defined a generic multiple purpose »helper« variable)—this really makes code hard to understand and is extremely error-prone. But even if variables are not misused, the number of variables to track alone has a decisive impact on how easy the code is to follow. That’s why we recommend ABAP procedures should regularly stay clearly below 100 lines.


The benefits of short procedures on comprehension, documentation, reuse, testing and profiling/debugging are independent from the used programming language. ABAP has indeed a more verbose syntax which justifies a higher threshold than 40 lines of code. Still we prefer to count lines, not statements since a single statement could be as complex as a single method. Since it is very important to keep the total number of declared local variables low in ABAP—as all are valid in the whole procedure—I’d recommend that for maintainable ABAP code it should be aimed to have procedures clearly shorter than 100 lines.

When we do quality analysis or quality control of an ABAP project, we apply usually a maximum length limit of 80 lines (or 60 lines when not counting blank and comment lines) to rate a procedure as green. For the vast majority of code, a procedure length of 80 (60) lines should be a reasonable limit. Of course, there will be always a few procedures for which it makes no sense to cut them into thus short parts, but these should remain an exception.

You must be Logged on to comment or reply to a post.
  • Great blog Christian, this is a key metric for code quality and good code structure.

    One note on SAP's default of 150 from the code inspector, in this metric it does not count every statement (i.e. everything that ends in a full stop) but groups or excludes some.  Specifically data declarations are not counted and 'closing' statements (e.g. ENDIF, ENDLOOP) are not added.

    So your 5 line example here would only count in the code inspector as 3 lines;

         DATA lv_i TYPE i.

         lv_i = get_min( ).

         WHILE lv_i <= get_max( ).

           " loop content

           lv_i = lv_i + 1.


    • Nick, thanks for your comment. True, Code Inspector would count '3' for that loop example - but statements, not lines. Contrary, Code Inspector would also count only '1' for my example of a rather complex SELECT.

      That's why I prefer to count lines, not statements since it better reflects how much code one has to read and understand. And since the DATA or END... and similar statements are also important when one want to understand the code, I'd count these to for lines.

  • Hi Christian,

    Thanks for this blog. It's an interesting aspect of code quality, I was not aware that there was already a code inspector check for this. I'll definitely have a look on it.

    I already heard horror stories about an include for a user exit in a customer system, which had such a long spaghetti-code, that it couldn't be any longer debugged, because the debugger crashed (in an older SAP release) 🙂 .



    • Hi Peter,

      I'm happy that you like the article. For the Code Inspector check: It actually does not exactly what was my post was mainly about - counting code lines. The check counts executable statements - with the back-draw of treating simple and easy to understand statements in the same way as pretty complex ones.



      • Hi Christian,

        You're right, the SCI checks are for counting the statements.

        Especially in 7.4 ABAP with the new SP/kernel even a single statement can be quite complex.



  • Great blog and kudos to your company for publishing the blogs on their site.  Although I only do ABAP coding I found many of them relevant and insightful. I only wish I could subscribe but the submission form didn't dispatch an email so I assume I didn't subscribe.

  • Hello Christian,

    I agree procedures should be small, but you seem to imply this can be achieved with automated control tools. I believe a change towards a coding style with shorter procedures requires a change of mind that is not easy to achieve, even with good tools.

    Most developers are not starting from scratch and enhancing existing procedures seem to be natural. Restructuring existing code is a risky business and refactoring (stepwise refinement supported by unit tests) requires strong discipline and unit tests.

    Further, our knowledge about a problem domain grows with experience. As a corollary we start coding when our understand is at the lowest point it will ever be ( 😕 so we better should have some feedback process built in..)

    Having smaller procedures has meant for me a change of coding style towards smaller method, and the creation of a lot of smaller classes with few methods to a level outside of the comfort zone of my earlier days. This goes with a major change in my view on the code towards a seam model as proposed by Michael Feathers.

    best regards,


    • Hello Jacques,

      thanks for your comment. Actually, my post didn't not focus so much on tooling, I wanted to discuss the relevance of method length for ABAP in general. Sorry, if the article was misleading in that way.

      I fully agree that a tool, especially an analysis tool, would not lead to better quality for its own. It's the people who must be aware of code quality. But tools may support these people. Even if enhancing an existing longtime grown custom code application, a good tool will be useful. E.g. when the tool simplifies it for you to focus on the quality issues in the code you just modified or the defects which were newly introduced.



  • Hi, Christian!

    Thanks for the post, it's a really good topic to discuss.

    I believe ABAP is more "wordy" than, for example, C++. Some new features mend the situation, but not all are lucky enough to have ABAP 7.40 with latest SPs.

    I can't but agree with your conclusion about code clarity, I try to keep my modularization units as small and simple as possible.

    Speaking about the exceptions from 80 (60) lines of code...  Just a usual case: I'm writing some ALV report with, for example, 40 columns. Readability of such report is another theme for discussion, but let users insist that everything is extremely necessary. Okay, I select some data with a number of small units or methods and then I need to put it together in one table. I usually have only one procedure which comprises all the logic. It may have a huge LOOP over the main table and a bulk of  READ TABLEs. Taking into account the following IF/ENDIF reading data from one table is a minimum of 4 lines of code. A couple of selection-screen checkboxes may blow up the logic.

    So, are such cases an exception? 🙂

    And commenting your paragraph about no block-local variables - I think, it's not a huge problem. Tons of global variables throughout the legacy code is a problem 🙂 And sometimes ABAP encourages us to use global variables - like ALV table for drilldown.

    • I usually have only one procedure which comprises all the logic. It may have a huge LOOP over the main table and a bulk of  READ TABLEs.

      Hi Nikolay,

      I am a stickler for "Separation of Concerns(SoC)" and "single responsibility". So although i have a method called BUILD_OUTPUT_TABLE( ), i put a little bit effort into thinking if i can modularise this method into smaller private methods. Sometimes i even create a local macro to do some simple calculation (e.g., adjusting the amounts depending on the debit/credit indicator).

      I agree with you that ABAP is verbose. Sometimes a READ TABLE statement can take 5-6 lines if you want to make it legible.

      My personal gripe is including comments while counting the LoC. I am a fan of writing comments in the code & sometimes i write a story why i cleared a variable or did not issue a COMMIT WORK 🙂

      Anyway, i agree with the OP's overall idea of keeping it short & simple 😳 A few days ago I was analysing a BAdI implementation which had >1000 LoC and it drove me crazy!!  😡



      • Hi, Suhas!

        Yep, concerning KISS principle - that's the way I like it (c).

        Lucky you are 🙂

        In our system there is a program for printing SD invoice which is over 4000 LoC and I don't know when I get enough time for refactoring cuz I believe that doing it partially will only make it worse.

        Local macro is quite ok for small and simple stuff, though still I try to simplify the task to the point where you can go without it.

        Comments are often a helper in analyzing huge portions of code, but self-commented code is probably the option we should try to reach. The only way I limit use of them is that I often write a "ptototype" code which will be replaced some days/weeks later. And I think that outdated comment is worse than the abcence of it.

        To sum it up, most of us try to make our life easier (and not only ours, but our followers' too).

        Returning back to my original question - I still want to get some opinions about what we can treat as exceptional cases for the rule of 80 (60) LoC? If we pretend to measure the quality of code by it's length (as one of the criteria) I think it's better to work out as detailed specification as possible for developers not just rely on their intuition.

    • Hi Nikolay,

      of course, there might be exceptions from a general rule on the procedure length limit. What developers should have in mind is that the overall goal is to write code which is easy to follow and understand. In most cases the longer a method, the harder to read it is.

      Exceptions from the length threshold should be only accepted if at least these conditions hold:

      1. The procedure is - besides its length - of a very simple structure without any complex constructs, only a few local variables, and almost no control blocks (not nested) and

      2. It's not possible to identify logical sub-parts in the code (Because the best way to structure logical parts is by separate procedures.)

      Especially for the second condition it is not possible to formalize it for an automated check. And I doubt it is possible to specify a complete list of exceptional cases, there will be always exceptions for the exceptions ...

      We aim this problem by observing the distribution of the source code: E.g. rate methods either green (up to 60 lines), yellow (up to 150 lines) or red (longer than 150 lines) and expect the majority of your code in "green" methods and only some code in the "yellow" section but there should be no method violating the red threshold. There might be still a few exceptions of methods which are better if longer than the red threshold, but these are blacklisted individually after a manual review. From our experience this is one step to keep your code base maintainable.



      • Thanks, Christian!

        That's what I meant to hear. At the current project I don't have much opportunities of working with good code, so I always ask myself whether I'm doing right things and producing a code of grood quality. I'm trying to follow the examples of best practice and bear in mind approximately the same things as those you've written about. Just wanted to be sure I'm moving in the right direction 🙂