/clean-abap

name: clean-abap
description: Clean ABAP style and maintainability guidance. Use when writing ABAP code or when a review explicitly asks for Clean ABAP style, readability, naming, structure, modern syntax, formatting, comments, or refactoring. For a general ABAP report correctness review, use abap-code-review-helper first; apply this skill second for style findings.
argument-hint: '[ABAP code task or ABAP code review request]'
user-invocable: true
disable-model-invocation: false

Clean ABAP — AI-Optimized Rules

> Distilled from the [SAP Clean ABAP Style Guide](https://github.com/SAP/styleguides). > Licensed under [Creative Commons BY 3.0](https://creativecommons.org/licenses/by/3.0/). > © SAP SE. Attribution preserved per license terms.

Apply ALL rules below when writing or reviewing ABAP code. Every rule is mandatory unless explicitly marked "consider".

Before writing, modifying, or reviewing ABAP code, read the `abap-code-review-helper` skill in full (skip if skill is unavailable), unless its complete contents are already available in your current context. Apply its correctness safeguards alongside these style rules; do not let a style preference change business behavior. Keep passed checks internal.

---

Names

• Use descriptive names that convey meaning. `customizing_entries` not `ce_tab`.
• Prefer solution domain terms (queue, tree) in technical layers, problem domain terms (account, ledger) in business layers.
• Use plural for collections: `materials` not `material_tab`.
• Use pronounceable names: `detection_object_types` not `dobjt`.
• Use `snake_case`. When hitting length limits, abbreviate the least important words.

  DATA max_response_time_in_millisec TYPE i.

• Avoid abbreviations. Use the same abbreviation everywhere for the same concept.
• Use nouns for classes/interfaces, verbs for methods. Prefix boolean methods with `is_` or `has_`.

  CLASS /clean/account.
  METHODS read_entries.
  IF is_empty( table ).

• Avoid noise words: `account` not `account_data`; `user_preferences` not `user_info`.
• Pick one word per concept: always `read_*`, never mix `read_this` with `retrieve_that`.
• Use pattern names (factory, singleton) only if the class actually implements that pattern.
• **No Hungarian notation or prefixes.** Drop `iv_`, `rv_`, `lt_`, etc.

  " good
  result = a + b.
  " bad
  rv_result = iv_a + iv_b.

• Do not shadow built-in functions (`condense`, `lines`, `strlen`, etc.) with method names.

Language

• Verify modern syntax is supported on the target release before using it.
• Do not optimize prematurely. Write clean code first, profile later.
• Prefer OO over procedural. Wrap function modules as thin shells around classes.

  FUNCTION check_business_partner [...].
    DATA(validator) = NEW /clean/biz_partner_validator( ).
    result = validator->validate( business_partners ).
  ENDFUNCTION.

• Prefer functional constructs:

  DATA(variable) = 'A'.              " not MOVE
  DATA(uppercase) = to_upper( str ). " not TRANSLATE
  index += 1.                        " not ADD 1 TO
  DATA(obj) = NEW /clean/cls( ).     " not CREATE OBJECT

• Use modern table expressions:

  DATA(line) = value_pairs[ name = 'A' ].

• Avoid obsolete elements. Use `@`-escaped host variables in SQL:

  SELECT * FROM spfli WHERE carrid = @carrid INTO TABLE @itab.

• Use design patterns only where they provide clear benefit.

Constants

• Use constants instead of magic numbers:

  IF abap_type = cl_abap_typedescr=>typekind_date.   " not 'D'

• Give constants descriptive names reflecting meaning, not value:

  CONSTANTS status_inactive TYPE mmsta VALUE '90'.     " not c_01

• Prefer `ENUM` (7.51+) over constants interfaces:

  TYPES: BEGIN OF ENUM type, warning, error, END OF ENUM type.

• If not using ENUM, group constants with `BEGIN OF ... END OF`:

  CONSTANTS:
    BEGIN OF message_severity,
      warning TYPE symsgty VALUE 'W',
      error   TYPE symsgty VALUE 'E',
    END OF message_severity.

Variables

• Prefer inline declarations at first use:

  DATA(name) = 'something'.

• Do not use a variable outside the block where it was declared.
• One `DATA` per variable — no chaining:

  DATA name TYPE seoclsname.
  DATA reader TYPE REF TO reader.

• Avoid field symbols when modern syntax suffices (2021+). Use `dref->*` directly.
• Loop targets:
• `ASSIGNING FIELD-SYMBOL(<line>)` — read/modify in place (fastest).
• `REFERENCE INTO DATA(line)` — when references needed outside loop.
• `INTO DATA(line)` — when you need a copy.

Tables

• `HASHED` — large, filled once, read often by unique key.
• `SORTED` — large, filled incrementally, read by full/partial key.
• `STANDARD` — small tables, arrays, or mixed access.
• Avoid `DEFAULT KEY`. Use explicit keys or `EMPTY KEY`:

  DATA itab TYPE STANDARD TABLE OF row_type WITH EMPTY KEY.

• Prefer `INSERT INTO TABLE` over `APPEND TO`.
• Use `line_exists( )` for existence checks:

  IF line_exists( my_table[ key = 'A' ] ).

• Prefer `READ TABLE` over `LOOP AT ... EXIT` for single-row retrieval.
• Prefer `LOOP AT ... WHERE` over nested IF inside LOOP.
• Avoid double reads — read once and catch the exception:

  TRY.
      DATA(row) = my_table[ key = input ].
    CATCH cx_sy_itab_line_not_found.
      RAISE EXCEPTION NEW /clean/not_found( ).
  ENDTRY.

Strings

• Use backtick literals for constants: `` DATA(s) = `ABC`. `` Not single quotes.
• Use string templates `| |` to assemble text:

  DATA(msg) = |HTTP { status_code }: { text }|.

Booleans

• Prefer enumerations when a third state may emerge. Use Booleans only for true binary states.
• Use `abap_bool` as the type. Use `abap_true`/`abap_false` for comparisons — never `'X'`, `' '`, or `IS INITIAL`.

  DATA has_entries TYPE a