The code inspector is an elaborate bit of kit, that can help yoo and your team avoid coding mistakes. I'm assuming you've discovered it's great potential and you have been delivering your own coding code-inspector-error-free for a long time now. Well done ! Would you like to do better ? Add your own checks.

There's an article on coding hazards (Hazards) which describes the way I like to work though my assignments. This article reveals how you can add your own code inspector check or test - which tests the availability of the word HAZARD in the development coding. The code inspector is an object-oriented setup, where categories and tests play an important role. You can add a category and add your test into the new category, or you can add your test into an existing category. To keep matters simple, that's what we'll do (never mind categories).

But first, get a feel on categories and tests through SE24, the class builder. On the screenshot below a few of the category and test classes have been highlighted. Feed them to SE24 and have a look around.

Coding is made available in a "scanned state", which is my wording for the results/output from the SCAN statement. It holds statements (positions to the tokens in a line of coding) and tokens (executable statements broken down to a singular language element) where e.g. the effect of using: with, and, more, commas is no longer relevant. You can base your checks on the "scanned state" of the abap (preferred) or you can do whatever else you would like to do, even selecting the Abap coding yourself.

Back to business: here's the instructions to create your own check:

• Copy class CL_CI_TEST_SCAN_TEMPLATE or simply create a new class which has CL_CI_TEST_SCAN as it's superclass. There's no need to create a transport for this (as code-inspecting is often regarded a development matter) yet there is also nothing to stop you making these checks available in your whole landscape.
• The copy is called ZCL_CI_TEST_HAZARDOUS for this example. After you have assigned the superclass (CL_CI_TEST_SCAN) generate the class. Add the attribute named C_MY_NAME type SEOCLSNAME and set the default value to 'ZCL_CI_TEST_HAZARDOUS'.
• Now create the CONSTRUCTOR (public) which should have coding to describe the test, link the test results to a category and place it there (position):

  method CONSTRUCTOR .
  
    SUPER->CONSTRUCTOR( ).
  
    DESCRIPTION = 'Hazardous comment reference'.
    CATEGORY = 'CL_CI_CATEGORY_STATISTICS'.
    VERSION = '000'.
    POSITION = '001'.
  
  endmethod.

• Then redefine the method GET_MESSAGE_TEXT (button Redefine, 2nd from the right ). This method should compose the message text that is reported in the code inspector.

  method GET_MESSAGE_TEXT.
  
    p_text = 'Developer notes found: &1'.
    
  endmethod.

• Last but not least method RUN, which you will also need to redefine. This is the method that performs the actual scan check. Where issues are found, the INFORM method is used to inform the code inspector of your findings.

  method RUN .
  
  * Based on CL_CI_TEST_FREE_SEARCH->RUN
    DATA: lv_tokennr LIKE statement_wa-from,
          lv_errcnt TYPE sci_errcnt,
          lv_code TYPE sci_errc,
          lv_position TYPE i,
          lv_param_1 TYPE string.
  
  * Get a scan
    IF ref_scan IS INITIAL.
      CHECK get( ) = abap_true.
    ENDIF.
    CHECK ref_scan->subrc = 0. "No scan results = no work to do
    lv_errcnt = 0.
  * Loop at all tokens
    LOOP AT ref_scan->statements INTO statement_wa.
      CHECK statement_wa-from <= statement_wa-to.
      lv_position = sy-tabix.
      LOOP AT ref_scan->tokens INTO token_wa
             FROM statement_wa-from TO statement_wa-to.
        lv_tokennr = sy-tabix.
  *     Search for string - in comments. The word HAZARD is the queue for this test
        IF ( token_wa-str CS 'HAZARD' or token_wa-str CS 'HAZARD' ) and
          ( token_wa-str(1) = '*' or token_wa-str(1) = '"'  ).
  
          lv_errcnt  = lv_errcnt + 1.
          lv_code    = 'HAZ001'.
          lv_param_1 = token_wa-str.
  *       Inform
          inform( p_sub_obj_type = c_type_include
                  p_sub_obj_name = get_include( )
                  p_position     = lv_position
                  p_line         = get_line_abs( lv_tokennr )
                  p_column       = get_column_abs( lv_tokennr )
                  p_errcnt       = lv_errcnt
                  p_kind         = C_ERROR "C_WARNING C_NOTE
                  p_test         = c_my_name
                  p_code         = lv_code
                  p_param_1      = lv_param_1 ).
  
          EXIT.
        ENDIF.
      ENDLOOP.
    ENDLOOP.
  
  endmethod.

• And there you have it: a fully functional test for the code inspector. All you need to do now is make it available on the code inspector. Start transaction SCI, find the menu below and the newly created class will be listed in the overview (also see below)

  

  ~

  The overview shows test-classes for the super class, which should at this point also show your own class.

  

• At this point, the test is ready to be used. To incorporate it in your daily checks, the code inspector check variant needs to be set. This can be done as a personal thing, or for all developers in the field.

  

  The default variant holds the settings on the checks/tests that are executed when the code inspector is used to inspect a given development. This is where you need to activate your new test.

  

Note that this setup only adds a test to the code inspector, which is probably as far as you and me would like to go. Have a look at the examples available if you feel you need to take this further. There's categories, there's also settings that are relevant for your test. And that's a few that I stumbled across setting up this tutorial. There's much more here !

• Prev
• Next