
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.
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
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:
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?
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.
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.
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.
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.
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:
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!!!
This is a good variant if you need to find out all obsolete function module usage in your code.
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.
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.
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.
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.
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.
This check variant collection is mainly checked against some concept from software engineering point of view.
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
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.
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:
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'.
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.
By the way, why we need to avoid high cyclomatic complexity?
Search based on various criterias could be performed according to your variant configuration.
The following operations on database table could be identified:
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.
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 * = *
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
3 | |
2 | |
2 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 |