0% found this document useful (0 votes)
76 views1 page

CleanABAPTheGoldenRulesV1 1 0

The document provides guidelines for writing clean and testable ABAP code. It recommends: 1) Using descriptive names and object orientation over imperative programming. 2) Keeping members private by default and testing principles like writing testable code. 3) Following readability rules like commenting code through code and optimizing for reading. 4) Using constants, right table types, and XSDBOOL for Booleans to improve code quality.

Uploaded by

zzg
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
76 views1 page

CleanABAPTheGoldenRulesV1 1 0

The document provides guidelines for writing clean and testable ABAP code. It recommends: 1) Using descriptive names and object orientation over imperative programming. 2) Keeping members private by default and testing principles like writing testable code. 3) Following readability rules like commenting code through code and optimizing for reading. 4) Using constants, right table types, and XSDBOOL for Booleans to improve code quality.

Uploaded by

zzg
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

Clean ABAP The Golden Rules

Names Don’t mix stateful and stateless in the Methods: Object orientation
same class
Use descriptive names Prefer instance to static methods
max_wait_time_in_seconds, iso3166tab. Classes: Scope METHODS a
CLASS-METHODS a
Language Members PRIVATE by default,
Public instance methods should be part
Prefer object orientation over PROTECTED only if needed
of an interface
imperative programming Testing: Principles INTERFACES the_interface.
METHODS a
I.e. classes over functions and reports Write testable code
Prefer functional over procedural There are no tricks to writing tests, there are only Methods: Method body
language constructs tricks to writing testable code. (Google)
Do one thing, do it well, do it only
E.g. index += 1 instead ADD 1 to index Enable others to mock you
CLASS my_super_object DEFINITION.
Descend one level of abstraction
Comments INTERFACES you_can_mock_this. do_something_high_level ( ).
DATA(low_level_op) = |a { b }|.
Express yourself in code, not in Readability rules
given_some_data( ). Keep methods small
comments do_the_good_thing( ). 3-5 statements, one page, 1000 lines
Delete code instead of commenting it and_assert_that_it_worked( ).
Methods: Parameter number
Formatting Test classes Aim for few IMPORTING parameters, at
Be consistent Call local test classes by their purpose best less than three
CLASS unit_tests METHODS a IMPORTING b c d e
Optimize for reading, not for writing CLASS tests_for_the_class_under_test
Split methods instead of adding
Constants Code under test OPTIONAL parameters
Use constants instead of magic Test interfaces, not classes METHODS a IMPORTING b
numbers DATA cut TYPE REF TO some_interface METHODS c IMPORTING d
DATA cut TYPE REF TO some_class METHODS x
E.g. typekind_date instead 'D' IMPORTING b
D
Tables Injection
Use test seams as temporary RETURN, EXPORT, or CHANGE exactly
Use the right table type
workaround one parameter
HASHED: large, filled at once, never modified,
METHODS do_it
read often They are not a permanent solution! EXPORTING a
SORTED: large, always sorted, filled over time or CHANGING b
Don’t misuse LOCAL FRIENDS to invade
modified, read often
STANDARD: small, array-like the tested code Error handling: Return codes
CLASS unit_tests LOCAL FRIENDS cut.
Booleans cut->db_reader = stub_db_reader Prefer exceptions to return codes
METHODS check RAISING EXCEPTION
Use XSDBOOL to set Boolean variables Test Methods METHODS check RETURNING result
empty = xsdbool( itab IS INITIAL )
Test methods names: reflect what’s Don’t let failures slip through
DATA(result) = check( input )
Conditions given and expected IF result = abap_false.
METHODS accepts_emtpy_user_input
Try to make conditions positive METHODS test_1
IF has_entries = abap_true. Error handling: Exceptions
Use given-when-then Exceptions are for errors, not for
Consider decomposing complex given_some_data( ).
conditions do_the_good_thing( ). regular cases
DATA(example_provided) = xsdbool(…) assert_that_it_worked( ).
IF example_provided = abap_true AND
Use class-based exceptions
one_example_fits = abap_true.
“When” is exactly one call METHODS do_it RAISING EXCEPTION
given_some_data( ). METHODS do_it EXCEPTIONS
do_the_good_thing( ).
Ifs and_another_good_thing( ). Error handling: Throwing
Keep the nesting depth low assert_that_it_worked( ).
ELSE.
Throw one type of exception
IF <other>. Assertions METHODS a RAISING EXCEPTION b c d
ELSE. Throw CX_STATIC_CHECK for
IF <something>.
Few, focused assertions
assert_not_initial( itab ). manageable situations
assert_equals( act = itab exp = exp ).
Regular expressions RAISE EXCEPTION no_customizing

Consider assembling complex regular Use the right assert type Throw CX_NO_CHECK for usually
assert_equals( act = itab exp = exp ).
expressions assert_true( itab = exp ). unrecoverable situations
CONSTANTS classes … RAISE EXCEPTION db_unavailable
CONSTANTS interfaces … Assert content, not quantity
… = |{ classes }|{ interfaces }|. assert_contains_message( key ) Error handling: Catching
assert_equals( act = lines( messages )
Classes: Object orientation exp = 3 ). Wrap foreign exceptions instead of
Assert quality, not content letting them invade your code
Prefer objects to static classes CATCH foreign INTO DATA(error).
assert_all_lines_shorter_than( … )
RAISE EXCEPTION NEW my( error ).
Prefer composition over inheritance RAISE EXCEPTION error.
DATA delegate TYPE REF TO
CLASS a DEFINITION INHERITING FROM

Clean ABAP The Golden Rules v1.1.0 PUBLIC https://github.com/SAP/styleguides/blob/master


/clean-abap/cheat-sheet/CheatSheet.md

You might also like