ABAP code inspector ( tcode SCI ) is not just a tool to ensure the correctness of your code. It is a powerful toolset for an ABAPer to make his life easier. This document is written based on Netweaver 7.40, unveiling some simple but useful tips about code inspector.

How to use ABAP code inspector

You could find the basic steps how to leverage code inspector from this blog: A Small tip to get all transparent tables used in ABAP code

How to read the inspection result

  • There are three columns Error, Warnings and Information. The result with error would probably need your high attention as most of the time it means the bad design or wrong usage about the features checked by inspection variant. The warnings and Information result are just suggestions or calculation result raised by code inspector. If you are 100% sure about your code behavior in all scenarios and runtime context, it is ok that you keep your current code unchanged. For example, in your code you do have some nested LOOP, however the two internal tables being looped are just configuration tables and would not have more than 10 entries for each in your application. In this dedicated case the nested loop will not lead to a great performance loss.
  • The documentation icon contains the corresponding help document for each check variant. The document contains quite a good demonstration about:

1. DOs and NOT TO DOs regarding given feature. By reading the document, you can learn how to write a correct, efficient, and robust ABAP code.

2. If you would like to suppress some waringing or information result, assuming if you are 100% sure about your code behavior in all scenarios and runtime context as mentioned before, you could achieve this by adding pseduo comment. The necessary pseduo comment could be found in each documentation.

  • By clicking the arrow button, you will navigate to variant customizing window. You could fine-tune the check variant there to perform the code inspection specifically for your project requirement.


Useful tips

The following parts are organized based on the original hierarchy in code inspection variant maintenance view, as displayed in the picture below:


General checks – Table Attribute Statistics

In the Technical Settings on database table in SE11, You can maintain “Buffering” and “Buffering Type” for a table. Code inspector will find out all combinations of these two settings which do not make sense, for example below:


Performance Check

Select-Statement can be transformed. X% of fields used

Suppose you have used a SELECT * FROM TABLE A in your method, after this SELECT statement, only number of B fields of table A are used in your method code, and the table A has totally number of C fields. Then code inspector will check whether the utilization rate of table fields ( B / C ) >= default value 20%. If the rate is less than 20%, it give you a hint that you should SELECT only those fields which are really needed in your code instead of SELECT *. You are able to change the default value 20% to any other value which suits your project requirement.


Search DB Operations in loops across modularization units

See one example below. Code inspector will find out all scenarios that a DB operation ( read or write ) is done within LOOP ( or even worse, within nested LOOP ) for you. In this example the table CRMD_DPP_HI_BLCK is read within the nested loop which leads to bad performance in application. Normally we will not directly access DB table in application code due to layer isolation design strategy, in this case we need to re-consider our code design: is there any other function module existing which supports the mass-read onm table CRMD_DPP_HI_BLCK?


Nested Loops

Nested loops can produce non-linear runtime behavior. In SAP delivered code there did exist many nested loops but the internal tables that the loop are operated on are mostly configuration tables, which means normally the internal table would not have too many entries. However you should think twice in your application code if you need to write nested loop on an application table which would potentially have lots of entries.

This variant will not only identify all nested “LOOP” statement but also other ABAP keyword which leads to loop behavior, like WHILE, DO etc.

Copy current table row for LOOP AT

nowadays it is well known to us all that it is better to use LOOP AT itab ASSIGNING <fs>.  (using a Field Symbol) or  LOOP AT itab REFERENCE INTO dref. (using a reference variable). This check variant gives you a very convenient way to identify all LOOP AT … INTO WA usage.

Low-Perform. Parameter Transfers

When we are designing the signature of class method or function module, we can decide whether a parameter should have “pass-value” or “pass-reference”, according to their dedicated use case. The general rule is that pass by value is always slower than pass by reference. The loss in performance is always a minimum of 40 % and can rise to several 1000 %, depending on the data type and data volume.

This check variant will provide you all potential in-efficient “pass-by-value” use cases. You could also customize the check variant to make the scan is done based on specific Type and Kind of Parameter that you are interested with.


Table Attribute Check

In the Technical Settings for a database table in tcode SE11, we can maintain Buffering setting for it. There is one option “The option “Buffering allowed, but switched off”, which is dedicated used for tables whose size category in the customer system cannot be predicted by the developer. Here, table in the customer system might be very large (in which case it should not be buffered) or relatively small (in which case it can be buffered).

So if one developer has marked this option on a table which has table size category 0 or 1, it become not valid since by selecting size category size to be 0 or 1, it indicates that the number of table entries has toplimit ( <= 11000 entries defined for size 1 ). In this case, “Buffering Activated” must be selected instead.

This check variant will identify all such incorrect table settings which may lead to potential performance loss for you.

Security Check – Dynamic and Client-Specific accesses in SELECT

As a developer in SAP, we are required to avoid any potential SQL injection in our code. The first step to achieve it is to find out all codes where the dynamic SELECT occurs. This check variant will scan all the following behaviors in your code:

  • Dynamic table accesses: SELECT * FROM (dbtab) WHERE …
  • Dynamic WHERE conditions: SELECT * FROM dbtab WHERE (where_cond)
  • Accesses to certain tables: SELECT * FROM dbtab WHERE …
  • Client-specific accesses: SELECT * FROM dbtab FROM WA … CLIENT SPECIFIED …

The variant “Dynamic and Client-Specific Accesses with INSERT, UPDATE, MODIFY, DELETE” does the similar logic.

Syntax Check/Generation – Extended Program Check

Return code(SY_SUBRC) for the EXCEPTION will not be processed after CALL FUNCTION

For example, if you call a function module which has declared several kinds of exceptions, however you didn’t evaluate them by checking sy-subrc after function module call, this behavior will be complained by code inspector.

             iv_para1                       = YYYY
            exception1_occurred             = 1
            exception2_occurred             = 2
            OTHERS                          = 3.

* an IF SY-SUBRC evaluation is missing here!!!

Function module … is flagged as obsolete

This is a good variant if you need to find out all obsolete function module usage in your code.

Robust Programming

Search for APPEND and INSERT … INDEX in SORTED Tables

To make things easier I use a small piece of code to demonstrate:

data: lt_table TYPE SORTED TABLE OF int4 WITH UNIQUE KEY table_line.
INSERT 2 INTO TABLE lt_table. " lt_table content: 2
INSERT 1 INTO TABLE lt_table. " lt_table ordered content: 1, 2
APPEND 4 TO lt_table. " lt_table ordered content: 1,2,4. No trouble here since fortunately 4 is the bigger than any value currently in lt_table
APPEND 3 TO lt_table. " DUMP!!!

This check variant will find out all use cases about APPEND or INSERT … INDEX done on a sorted table. Although not all of those will lead to runtime DUMP, a robust code should not count on those uncertainties but try to avoid them from beginning.

Empty Unused Procedures

This check variant returns all Identification of the function modules & class methods which are empty  not yet been called in the current system. For methods and function modules which are not remote-enabled ones, they are good candidates to be deleted during your code-refacting.

Check of SY-SUBRC Handing

Most executable ABAP keywords will set the value of system variable SY-SUBRC accordingly. A robust code should always evaluate its value every time an ABAP statement containing those keywords are executed and react correspondingly.

You can customize the check variant to fine-tune your own SY-SUBRC handling check behavior.


Suspect Conversions

For example, the conversion from a Literal variable to another variable with ABAP type is regarded as “Suspect conversion”.   Assignment from a structure variable to a character-like variable is also considered to be suspect conversions. Basically the help document from “F1->ABAP Programming Guidelines->Robust ABAP->Assignments, Calculations, and Other Types of Data->Using Conversion Rules” is dedicatedly for conversion and worth reading.


Missing table content check before calling SELECT … FOR ALL ENTRIES IN

In case the internal table used in FOR ALL ENTRIES statement is empty, the DB table would unexpectedly be read completely.

The guideline is always try to check the internal table content first, that is, to embrace FAE statement with an IF <internal table> IS NOT  INITIAL prerequisite check.

Programming Conventions

Naming conventions

You could define naming convention currently used in your team or reuse the default setting below. Any violation on the convention will be reported by code inspector.



Metrics and Statistics

This check variant collection is mainly checked against some concept from software engineering point of view.

Number of Executable Statements Metrics

This variant will calculate the number of executable statement for each method of a given ABAP class ( or other ABAP artifact such as function module, report etc ). You could also define the “comment rate”, for example there is an input field in variant configuration:

warn if < … comments per 100: 10 ( default value, could be changed )

Then you could see the following inspection result for example:

Number of comments is 3 per 39 executable

Statements => falls below limit of 10% ( calculated by the variant configuration: 10 ( default value, could be changed ) / 100

FAN-OUT Structural Metrics

This terminology comes originally from Semiconductor Industry: “Fan-in is the number of inputs a gate can handle.” ( from wikipedia )

In software engineering, the concept fan-in and fan-out are used to monitor and measure the interaction among modules in the application. According to structured programming idea, an application consists of modules which is responsible to implement a relatively independent functionality.

Fan-in: the number of modules which calls the current module being discussed. The larger fan-in is, the better reusability the current module gains.

Fan-out: The number of modules that the current module calls in its code. The larger fan-out is, the more complex the module is. A module with fan-out = 1 usually indicates that it is just a wrapper which delegates the call to the module within it. A large fan-out means the module has many dependencies on other modules. In this case, you may think twice about your current design: Is it possible to introduce some new intermediate module to reduce fan-out value?

To get a better understanding on fan-out, please refer to attachment “example – why fan-out of method GET_OPPORTUNITY_RESULT is calculated as 7.txt“.

This check variant will calculate the fan-out value of each ABAP class method and also a cumulative fan-out value of the ABAP class by summing up all fan-out values of its method.

Comment Language Metrics

There is argument that in code-refacting topic, suppose a piece of code is not needed any more, should we comment it out or just directly remove it? Back to ABAP, if you have requirement to identify all location where some ABAP code are commented out, this check variant is your best choice. Besides comment identification functionality, this variant also provides the following features:


  • Number of German comment lines
  • Number of English comment lines
  • Number of comment lines in unknown language
  • Number of lines of commented out ABAP
  • Number of pseudo-comments

OO Size Metrics

The following statistics could be displayed for a given ABAP class.

  • Number of methods

     In variant configuration, you can also set further filter like: number of private, protected, and public methods, number of re-defined methods .

  • Number of attributes

     In variant configuration, you can also set further filter like: number of private, protected, and public methods .

  • Number  of interfaces
  • Number of events

Program Complexity Test – cyclomatic complexity

From wikipedia, the cyclomatic complexity of a program is defined with reference to the control flow graph of the program, a directed graph containing the basic blocks of the program, with an edge between two basic blocks if control may pass from the first to the second. The complexity M is then defined as:

M = E − N + 2, where

E = the number of edges of the graph.

N = the number of nodes of the graph.

Take this very simple report for example, it has cyclomatic complexity calculated as 3 by code inspector.

DATA: lv_value TYPE i VALUE 1.
IF lv_value = 1.
  WRITE: / 'always happend'.
ELSEIF lv_value = 2.
  WRITE: / 'not possible'.
  WRITE: / 'even not possible'.

Why calculated as 3? See the directed graph for this simple report below:


E: 3 ( black, red and green edgs )

N: 2 ( two blue diamond blocks )

As a result M = 3 – 2 + 2 = 3.

By the way, why we need to avoid high cyclomatic complexity?

Search functions

Search based on various criterias could be performed according to your variant configuration.

Search DB Operations

The following operations on database table could be identified:


Find Unwanted Language Elements

Some ABAP keyword should be forbidden under certain programming context, for example all List processing keywords like WRITE, FORMAT, ULINE etc should not be used in Enterprise service development environment. Of course in variant configuration you could add any other keywords which are unwanted in your project.

Search ABAP Statement Patterns

Compare with another very useful source code scan report RS_ABAP_SOURCE_SCAN, it also supports source code scan based on statement pattern, not statement itself. For example if you need to identify all use cases of “Read table with key”, you only need to specify the following search pattern in variant configuration: ( * stands for any characters in the given position )


And it works like a charm:


So if you would not like to spend time to prepare the complex regular search string for

RS_ABAP_SOURCE_SCAN, you can try this approach.


if the current functionalities provided by existing check variant could not fulfill your specific requirement, you can create your own check variant by following the steps in this blog: Code Inspector – How to create a new check .

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply