How to configure the SAP Code Inspector to.....

[Former Member]

Following on from my earlier blog covering Setting up and using the SAP Code Inspector, I thought I’d focus in on some of the more useful checks and how to get the most out of them.

....check for development standards

Any extensive development standards will have guidelines on the required conventions for variable naming.  For example, global variables should begin with G and local variables with L, followed by TY for Type, C for constant and so on.  A code inspector variant can be created that contains the settings specific to your development standards.

Configure the settings in the node List of Checks -> Programming Conventions -> Naming Conventions.  SAP provides some settings by default (and if you were writing standards from scratch you could do worse than adopt these).

If you have your own conventions you will need to remove the SAP recommended ones.

Program Global – This covers the convention for global data declarations, those declared in the TOP include or the main program.  Here the defaults provide a reasonable starting point, but there is scope for a more complex convention.   For example, it could be required that all global definitions start with G, followed by a letter to identify the type (C for Constant, V for Variable, S for Structure etc).

Proced. Local – This covers the convention for local data declarations, those declared in subroutines or PAI/PBO modules.  Again the defaults provide a reasonable starting point, but could be extended to prefix all local declarations with L before a letter to identify the type.

Global Classes/Interfaces – This covers Classes and Interfaces defined in transaction SE24.  The defaults provide a reasonable starting point but can be adapted where your own standards exist.  More complex definitions can be checked in the next section (List of Checks -> Programming Conventions -> Extended Naming Conventions for Programs).  Interestingly, if any options in this section of the check are configured a check on program name is performed.

Local Classes/Interfaces – As above, but for Classes and Interfaces defined within programs, not stand-alone objects.

Method Parameters – Covers the convention, obviously for method parameters.  The default of a P_ prefix is reasonable, but could be extended to also indicate the direction of the parameter (e.g. PI_, PE_ etc) or the type (e.g. PS_ for structure, PV_ for variable).

Event Parameter – Covers the convention for the exporting parameter in Class or Interface Events.

Functions – As far as I can tell, these settings aren’t taken into consideration in the check.  If you want to check Function module conventions you’ll need to use the next check (List of Checks -> Programming Conventions -> Extended Naming Conventions for Programs). 

Forms – Here you can specify the required format of the subroutine name as well as the various parameter types.  The default of P_* is also the default format if you let the ABAP editor create the subroutine automatically.

Also, you can activate the settings in List of Checks -> Programming Conventions -> Extended Naming Conventions for Programs to extend some of the settings above.

Functional Programming Only - Here you can specify the required format of the Function module name (for example checking for an underscore in the second position) as well as the convention of the parameter types.  The check for function module name may need note 1223022 applying before it will work.  If you wanted to ensure that obsolete TABLES parameters were not being used you could exclude the pattern A* to Z* and this would highlight any function modules with TABLES parameters defined.

....check for DDIC table settings

Code inspector can also be used to check the technical settings on tables.  Particularly it checks the relationships between the buffering settings and the other technical settings.  Maybe it’s because I’m fanatical about getting the settings right on customer created tables, but I think these checks are useful.  They’re under List of checks -> Performance Checks -> Table attributes Check, and require no configuration.  There are four sets of checks available, and each group of checks can be turned on or off.  The specific checks themselves are well documented in SCI, so I’ll not repeat that here.

....check that code can be supported

A key element for the support of code is that it is well structured and adequately commented.  To check this we can configure the settings in the node List of Checks -> Metrics and Statistics -> Number of Executable Statements Metrics.  Of most interest here is the check on the number of executable statements in each processing block (e.g. subroutine) or development object (e.g. program or function module).   It is possible to configure the check to highlight objects with more than or less than a certain number of statements.  This can be used to ensure effective modularisation of code, large blocks of code become difficult to analyse and support and effective use of subroutines is important.

The other check here is for the ratio of comments to executable code as a percentage.  The default is 10 percent, and this is a reasonable starting point, although for small processing blocks is not particularly valid.  As a method of identifying code that is light on comments it is very good, and you can change the percentage based on the results that it gives in the inspection, but 10 percent is a pretty reliable measure. 

In the check, List of Checks -> Metrics and Statistics -> Comment Language Metrics there is one check of particular use which is the check for blocks of commented out ABAP.  Blocks of commented out ABAP make code difficult to read and navigate though and are unnecessary when version management is used (in fact, commented out ABAP makes version history harder to use as well).  The amount of contiguous code to check for is configurable and the default is 4 lines.  This check also includes a check for German comments (something I imagine SAP developed for their own use....), but more usefully can check for pseudo comments ("#EC....), so if a specific Code Inspector warning has been hidden by a pseudo comment these can be found.