Code Inspector 002
Code Inspector 002
Code Inspector 002
Useful tips
o
Performance Check
Nested Loops
Robust Programming
Page 1
Suspect Conversions
Missing table content check before calling SELECT ... FOR ALL
ENTRIES IN
Programming Conventions
Naming conventions
OO Size Metrics
Search functions
Search DB Operations
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.
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
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.
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:
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:
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.
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?
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.
Page 6
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.
Page 7
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.
= YYYY
EXCEPTIONS
exception1_occurred
=1
exception2_occurred
=2
OTHERS
= 3.
data: lt_table TYPE SORTED TABLE OF int4 WITH UNIQUE KEY table_line.
INSERT 2 INTO TABLE lt_table. " lt_table content: 2
Page 8
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.
Suspect Conversions
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.
Page 10
Page 11
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
Page 12
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
Page 13
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
Take this very simple report for example, it has cyclomatic complexity calculated as
3 by 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:
Search functions
Search based on various criterias could be performed according to your variant
configuration.
Search DB Operations
Page 15
SELECT
DELETE
UPDATE
MODIFY
INSERT
OPEN CURSOR
FETCH
CLOSE CURSOR
EXEC SQL
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 )
Page 16
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 .
Page 17