abapOpenChecks

repository·main·Indexed 43 days ago

https://github.com/larshp/abapopenchecks

Open-source checks for SAP Code Inspector (SCI) and ABAP Test Cockpit (ATC) designed to extend static analysis capabilities of the ABAP platform. It provides rules to enforce Clean ABAP principles, identify obsolete statements, and detect modern syntax incompatible with versions prior to v740sp02 for downporting purposes.

Tokens
18.1K
Snippets
51
Records
159
Agent score
54%

What's inside abapOpenChecks

  1. Overview of abapOpenChecks

    main

    abapOpenChecks is a collection of custom checks designed for use with SAP Code Inspector (SCI) or ABAP Test Cockpit (ATC). These checks can be customized to meet specific application requirements and scenarios.

    Note that performance may vary, and some checks might be slow or produce incorrect results in certain contexts. Users are encouraged to report errors via GitHub issues.

  2. Check for redundant RETURN, CLEAR, FREE, CHECK, or EXIT statements

    main

    The CHECK_27 check identifies redundant statements that occur at the very end of a code block (such as a FORM, METHOD, or FUNCTION). If the statement is the last one before the block terminates, it can be removed without changing the program's behavior.

    Redundant patterns include:

    • RETURN at the end of a block.
    • CLEAR or FREE at the end of a block.
    • CHECK or EXIT at the end of a block.
    ... 
      IF p_subrut[] IS INITIAL.
        WRITE: / 'foobar'.
        RETURN. " Redundant if this is the last statement in the block
      ENDIF.
    ENDFORM.
  3. Understand the 'No public attributes' check (CHECK_84)

    main
    The CHECK_84 check ensures that global objects do not have public attributes. This check is specifically designed for global Interface (INTF) and Class (CLAS) objects. It is intended to enforce encapsulation by preventing direct access to attributes from outside the object.
  4. Avoid using system variables for MESSAGE statements

    main

    The CHECK_71 check identifies code that uses default Eclipse exception handling patterns, specifically using system variables like sy-msgid, sy-msgty, sy-msgno, etc., within a MESSAGE statement.

    Using this pattern can be risky because not all standard SAP Function Modules (FMs) or custom Z-FMs throw messages in a way that is compatible with this exception handling, which may lead to ST22 runtime errors (dumps).

    * Avoid this pattern:
    message id sy-msgid type sy-msgty number sy-msgno
               with sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
  5. Detect CLEAR as first use of variable (CHECK_79)

    main

    The CHECK_79 check identifies instances where a variable is explicitly cleared using the CLEAR statement immediately after it has been defined, before any other meaningful usage. This is often redundant as local variables are initialized to their type-specific initial values upon definition.

    Limitation: This check currently only works for local variables within global classes.

    METHOD foobar.
    
      DATA lv_index TYPE i.
      CLEAR lv_index. 
      ..
    
    ENDMETHOD.
  6. Avoid accessing table body via brackets (CHECK_48)

    main
    Internal tables with header lines are obsolete in modern ABAP. Consequently, accessing the table body using the [] syntax is unnecessary and should be avoided. This check flags usage of [] for table body access to encourage cleaner, modern syntax.
  7. Understand the CHECK_59 logical expression structure check

    main

    The CHECK_59 check enforces clean and unambiguous logical expression structures in ABAP. It aims to prevent two common issues:

    1. Redundant Parentheses: It flags expressions that use excessive parentheses where the operator precedence makes them unnecessary (e.g., IF ( ( foo = bar ) AND ( moo = boo ) ).).
    2. Ambiguous Expressions: It flags expressions that lack necessary parentheses to clarify the order of operations, especially when mixing AND and OR operators (e.g., IF foo = bar AND moo = boo OR laa = baa.).

    Limitation: This check may fail to function correctly if variables are named using ABAP keywords such as AND, IF, or OR.

    * Bad: Too many parentheses
    IF ( ( foo = bar ) AND ( moo = boo ) ).
    
    * Good: Clean structure
    IF foo = bar AND moo = boo.
    
    * Bad: Ambiguous (missing parentheses)
    IF foo = bar AND moo = boo OR laa = baa.
    
    * Good: Explicit precedence
    IF ( foo = bar AND moo = boo ) OR laa = baa.
  8. Retrieve the system call stack

    main

    To obtain the current system call stack in ABAP, you can use the function module SYSTEM_CALLSTACK.

    Alternatively, you can use the following methods from class CL_ABAP_GET_CALL_STACK:

    • GET_CALL_STACK: To retrieve the stack.
    • FORMAT_CALL_STACK_WITH_STRUCT: To retrieve and format the stack using a structure.
  9. Avoid using EXIT outside of loops

    main
    The CHECK_02 check enforces that the EXIT statement is only used within loop structures. To end the current processing block (such as a method or function module) without a loop, use the RETURN statement instead. This check aligns with SAP standard programming guidelines found in the 'Extended Program Check'.
  10. Use explicit keys for internal tables (CHECK_48)

    main
    To comply with modern ABAP standards (Release 7.40+), avoid relying on implicit default keys for internal tables. When declaring or using internal tables, you should explicitly specify the table key or use EMPTY KEY to avoid ambiguity. This check ensures that code follows these best practices for internal table key definitions.
  11. Identify new syntax for ABAP downporting (CHECK_100)

    main
    The CHECK_100 rule set is designed to help developers identify modern ABAP syntax that is incompatible with older ABAP versions (prior to ABAP 7.40). This is essential when code needs to be 'downported' to run on older SAP NetWeaver releases. The check flags various modern features including inline declarations, constructor operators, iteration expressions, and more.