You are on page 1of 17

Useful tips regarding ABAP code inspector that you may not know

Last Updated: June 22nd 2015 by Admin


+

How to use ABAP code inspector

How to read the inspection result

Useful tips
o

General checks - Table Attribute Statistics

Performance Check

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

Search DB Operations in loops across modularization units

Nested Loops

Copy current table row for LOOP AT

Low-Perform. Parameter Transfers

Table Attribute Check

Security Check - Dynamic and Client-Specific accesses in SELECT

Syntax Check/Generation - Extended Program Check

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


after CALL FUNCTION

Function module ... is flagged as obsolete

Robust Programming

Search for APPEND and INSERT ... INDEX in SORTED Tables

Empty Unused Procedures

ABAP CODE INSPECTOR

Page 1

Check of SY-SUBRC Handing

Suspect Conversions

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

Programming Conventions

Naming conventions

Metrics and Statistics

Number of Executable Statements Metrics

FAN-OUT Structural Metrics

Comment Language Metrics

OO Size Metrics

Program Complexity Test - cyclomatic complexity

Search functions

Search DB Operations

Find Unwanted Language Elements

Search ABAP Statement Patterns

Extension

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

ABAP CODE INSPECTOR

Page 2

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.

ABAP CODE INSPECTOR

Page 3

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:

ABAP CODE INSPECTOR

Page 4

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?

ABAP CODE INSPECTOR

Page 5

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.

ABAP CODE INSPECTOR

Page 6

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)

ABAP CODE INSPECTOR

Page 7

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.

CALL FUNCTION 'XXXX'


EXPORTING
iv_para1

= YYYY

EXCEPTIONS
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

ABAP CODE INSPECTOR

Page 8

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

ABAP CODE INSPECTOR

Page 9

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.

ABAP CODE INSPECTOR

Page 10

ABAP CODE INSPECTOR

Page 11

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

ABAP CODE INSPECTOR

Page 12

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

ABAP CODE INSPECTOR

Page 13

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.

ABAP CODE INSPECTOR

Page 14

IF lv_value = 1.
WRITE: / 'always happend'.
ELSEIF lv_value = 2.
WRITE: / 'not possible'.
ELSE.
WRITE: / 'even not possible'.
ENDIF.

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.

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:

ABAP CODE INSPECTOR

Page 15

SELECT

DELETE

UPDATE

MODIFY

INSERT

OPEN CURSOR

FETCH

CLOSE CURSOR

EXEC SQL

Find Unwanted Language Elements

Some ABAP keyword should be forbidden under certain programming contenxt, 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 )

READ TABLE * WITH KEY * = *

ABAP CODE INSPECTOR

Page 16

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.
Extension
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 .

ABAP CODE INSPECTOR

Page 17

You might also like