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).
![sci_proceduarl_metrics_config.png]()
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:
CALL FUNCTION 'Z_CALCULATE_RESULT'
EXPORTING
iv_x = lv_x
iv_y = lv_y
iv_z = lv_z
IMPORTING
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.
ENDWHILE.
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.
Summary
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.
