Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
Showing results for 
Search instead for 
Did you mean: 
Active Contributor
You probably know that it is possible to customize the Code Inspector in order to check the naming conventions of your variables. This is really useful and flexible.

But there is a problem: the check is done across all sub-objects of your program meaning that if you decide to reuse some standard includes, then the check is applied also to those.

Most of (older) standard programs do not comply with your own naming conventions even if they follow tightly the ones from SAP itself.

There are two main situations where you want to reuse such code objects:

- it exists an include containing all needed constants for a given scenario (MM, SD, ...)
- it exists a type-pool containing all needed types

What would be a solution ? In my opinion, Code Inspector should check only custom objects and not standard objects. So we have to find out how to separated those two sets of objects.

The first idea would be to look at the namespaces: if the program name starts with Y or Z then it is a custom object. But this logic does not apply to all kinds of programs because we have a lot of programs which are generated and do not follow this rule.

Here is the good idea: let's retrieve the Package (or "development class" for veterans) of the object and check if this package is flagged as being custom. This way we are sure to retrieve all custom objects even if the name has been generated by SAP (like a function linked to a Smartform, or a program executing a Query)...

For the type-pool the problem is a little bit different: we can still create type-pools but the variable must start with type type-pool name. So naming convention (in a Code Inspector perspective) is impossible to follow.

Currently the Code Inspector does not allow to exclude some objects in a smart way. So we have to be creative and find the spot giving us a chance to interact with the object list.

This can be done in the method HANDLER of the standard class CL_CI_INSPECTION.
Let's create an implicit enhancement at the beginning of this method.
Here is the code that you have to put in it:
  method handler .
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""$"$\SE:(1) Class CL_CI_INSPECTION, Method HANDLER, Start A
*$*$-Start: (1)---------------------------------------------------------------------------------$*$*
INCLUDE rddkorri.

CONSTANTS: lc_pgmid TYPE tadir-pgmid VALUE 'R3TR',
lc_tpool TYPE tadir-pgmid VALUE 'TYPE'.

DATA: lv_devclass TYPE tdevc-devclass,
lv_devtype TYPE ko015-devc_type.

IF p_obj_type = lc_tpool.

SELECT SINGLE devclass FROM tadir
INTO lv_devclass
WHERE pgmid = lc_pgmid
AND object = p_sub_obj_type
AND obj_name = p_sub_obj_name.
IF sy-subrc NE 0.
SELECT SINGLE devclass FROM tadir
INTO lv_devclass
WHERE pgmid = lc_pgmid
AND object = p_obj_type
AND obj_name = p_obj_name.

IF sy-subrc = 0.
wi_devclass = lv_devclass
we_devc_type = lv_devtype.

IF lv_devtype <> devc_customer.

*$*$-End: (1)---------------------------------------------------------------------------------$*$*

As you can see, even this small piece of code illustrates the usage of existing includes. The include RDDKORRI is used here to give the list of all possible types of Development classes.

When the enhancement is activated, you will get shorter lists in the results of Code Inspector and you will be able to concentrate on the real problems, not the errors coming from standard programs/includes !