marcellourbani/clean-abap

Clean ABAP — AI-Optimized Rules

Distilled from the SAP Clean ABAP Style Guide. Licensed under Creative Commons 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".

---

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 abap_bool.
  IF has_entries = abap_false.
  

• Use xsdbool( ) to set Booleans:

  DATA(has_entries) = xsdbool( line IS NOT INITIAL ).
  

Conditions

• Prefer positive conditions. Avoid double negatives.
• Prefer IS NOT over NOT IS, <> over NOT =.
• Use predicative method calls for Boolean methods:

  IF condition_is_fulfilled( ).    " not = abap_true
  

• Decompose complex conditions into named Boolean helpers.
• Extract complex conditions into dedicated methods.

Ifs

• No empty IF branches — negate instead.
• Prefer CASE over ELSE IF chains.
• Keep nesting depth low — flatten with sub-methods, Boolean helpers, or AND.

Regular Expressions

• Prefer simple string methods over regex when possible.
• Prefer existing SAP basis checks over hand-written regex.
• Assemble complex regex from named constants.

Classes

Object Orientation

• Prefer objects to static classes. Static defeats mocking.
• Exception: stateless utility classes with pure functions are acceptable as static.
• Prefer composition to inheritance.
• Don't mix stateful and stateless in the same class.

Scope

• Global classes by default. Local only for private structures, complex algorithms, or test injection.
• Mark classes FINAL unless designed for inheritance.
• Members PRIVATE by default. PROTECTED only for intentional subclass override.
• For immutable objects, prefer READ-ONLY attributes over getters:

  DATA name TYPE string READ-ONLY.
  

Constructors

• Prefer NEW to CREATE OBJECT. Use CREATE OBJECT only for dynamic types.
• If CREATE PRIVATE, keep CONSTRUCTOR in PUBLIC SECTION.
• Prefer multiple static creation methods over optional constructor parameters:

  CLASS-METHODS new_from_template IMPORTING template TYPE REF TO zcl_tmpl
    RETURNING VALUE(result) TYPE REF TO zcl_doc.
  CLASS-METHODS new_from_name IMPORTING name TYPE string
    RETURNING VALUE(result) TYPE REF TO zcl_doc.
  

• Use singletons only when multiple instances genuinely don't make sense.

Methods

Calls

• Call static methods via class name, not instance:

  cl_my_class=>static_method( ).     " not lo_instance->static_method( )
  

• Access types via class name, not instance.
• Prefer functional call style. Use CALL METHOD only for dynamic dispatch.
• Omit RECEIVING — capture return value directly.
• Omit the optional EXPORTING keyword.
• Omit parameter name in single-parameter calls (unless ambiguous).
• Omit me-> unless resolving a scope conflict.

Object Orientation

• Prefer instance methods. Static only for factories.
• Public instance methods should be part of an interface.

Parameters

• Aim for < 3 IMPORTING parameters. Combine related ones into structures.
• Split methods instead of adding OPTIONAL parameters.
• Use PREFERRED PARAMETER sparingly.
• Return/export/change exactly one parameter. Return a structure for multi-part output.
• Prefer RETURNING over EXPORTING — enables functional style.
• RETURNING large tables is okay — don't prematurely switch to EXPORTING.
• Don't mix RETURNING with EXPORTING/CHANGING.
• Use CHANGING sparingly — only for in-place updates.
• Split methods instead of Boolean input parameters:

  update_without_saving( ).     " not update( do_save = abap_true )
  update_and_save( ).
  

• Name RETURNING parameter RESULT:

  METHODS get_name RETURNING VALUE(result) TYPE string.
  

Parameter Initialization

• Always clear/overwrite EXPORTING reference parameters at method start.
• Beware same-variable input/output — defer CLEAR if needed.
• Don't clear VALUE parameters (already empty).

Method Body

• Do one thing, do it well, do it only.
• Focus on happy path OR error handling, not both. Extract validation separately.
• Descend one level of abstraction per method.
• Keep methods small: 3-5 statements, max ~20.

Control Flow

• Fail fast — validate inputs at top before expensive work.
• Prefer IF ... RETURN over CHECK. Use CHECK only at method start.
• Never use CHECK inside loops — use IF + CONTINUE.

Error Handling

Messages

• Use MESSAGE e001(ad) INTO DATA(message). for where-used traceability.

Return Codes

• Prefer exceptions to return codes.
• Check legacy return codes and convert to exceptions.

Exceptions

• Exceptions are for errors only, not regular cases.
• Use class-based exceptions (TRY/CATCH), not legacy EXCEPTIONS.

Throwing

• Create abstract app-specific super classes per exception category.
• Throw one exception type per method; use sub-classes for distinction.
• CX_STATIC_CHECK for manageable expected exceptions.
• CX_NO_CHECK for usually unrecoverable situations.
• CX_DYNAMIC_CHECK only when caller controls whether it can occur.
• Dump only for totally unrecoverable programming errors.
• Prefer RAISE EXCEPTION NEW to RAISE EXCEPTION TYPE:

  RAISE EXCEPTION NEW cx_gen_error( previous = exception ).
  

Catching

• Wrap foreign exceptions — don't let them invade your API:

  CATCH cx_amdp_failure INTO DATA(ex).
    RAISE EXCEPTION NEW cx_generation_failure( previous = ex ).
  

Comments

• Express yourself in code, not comments. Extract methods with descriptive names.
• Comments are no excuse for bad names.
• Write comments for the why, not the what.
• Comment with ", not *.
• Put comments before the statement they relate to.
• Delete dead code — don't comment it out.
• No manual versioning with ticket/transport markers.
• Use FIXME, TODO, XXX with your user ID.
• No method signature or end-of comments.
• ABAP Doc only for public APIs consumed by other teams.
• Prefer pragmas (##NEEDED) to pseudo comments ("#EC NEEDED).

Formatting

• Be consistent with your team's style.
• Use the ABAP Formatter before activating.
• One statement per line.
• Max line length: 120 characters.
• Condense — no unneeded blanks.
• Single blank lines to separate, never more.
• Align assignments to the same object only:

  structure-type = 'A'.
  structure-id   = '4711'.
  

• Close brackets at line end, not on new line.
• Single-parameter calls on one line.
• Parameters behind the call; break only if too long.
• Indent broken parameters under the call.
• One parameter per line for multi-parameter calls.
• Align parameters vertically.
• Indent and snap to tab.
• Don't align TYPE clauses across different declarations.
• Don't chain assignments.

Testing

Principles

• Write testable code. Refactor if needed.
• Enable mocking — add interfaces at outward-facing places.
• Test code must be even more readable than production code.
• Automate — no $TMP copies or manual test reports.
• Test publics only. Needing to test privates signals design flaw.
• Don't obsess about coverage numbers.

Test Classes

• Name by purpose: ltc_reads_entry, not ltc_test.
• Unit tests in the local test include.
• Component/integration tests in separate FOR TESTING ABSTRACT global class.
• Shared helpers in lth_* classes.

Code Under Test

• Variable name: cut (default) or meaningful name.
• Type against interface, not class.
• Extract the call to CUT into its own method.

Injection

• Use constructor injection for test doubles.
• No setter injection, no FRIENDS injection.
• Consider cl_abap_testdouble over hand-written doubles:

  DATA(mock) = CAST if_reader( cl_abap_testdouble=>create( 'if_reader' ) ).
  cl_abap_testdouble=>configure_call( mock )->returning( value ).
  

• Test seams only as temporary workaround.
• LOCAL FRIENDS only for CREATE PRIVATE constructor access.
• Don't mock what the test doesn't need.
• Don't build test frameworks with case-ID dispatching.

Test Methods

• Name reflects given + expected: reads_existing_entry, throws_on_invalid_key.
• Structure: given-when-then. Extract sub-methods if long.
• "When" = exactly one call to CUT.
• No TEARDOWN unless cleaning external resources.

Test Data

• Meaningless data must look meaningless: '42', '?=/"&'.
• Make differences easy to spot.
• Use constants for test data purpose.

Assertions

• Few, focused assertions per test method.
• Use the right assert type: assert_equals, assert_false — not assert_true( xsdbool(...) ).
• Assert content, not quantity.
• Assert quality, not content (for meta-properties).
• Use fail( ) after CUT call for expected exceptions:

  TRY.
      cut->do_something( '' ).
      cl_abap_unit_assert=>fail( ).
    CATCH /clean/some_exception.
  ENDTRY.
  

• Forward unexpected exceptions via RAISING on the test method.
• Write custom assert methods to reduce duplication.