SAP Style Guides

repository·main·Indexed 24 days ago

https://github.com/sap/styleguides

SAP's style guides for coding, featuring the ABAP Code Review Guide. It provides methodologies, tools, and best practices for conducting ABAP code reviews, including workflows for one-way and two-way synchronization with Git using abapGit or gCTS. The documentation covers automated checks with abaplint, ATC, and ABAP Unit tests, as well as Clean ABAP guidelines and cheat sheets.

Tokens
157.6K
Snippets
490
Records
760
Agent score
83%

What's inside sap-styleguides

  1. Overview of Clean ABAP Guide

    main

    The Clean ABAP guide is a set of coding standards and best practices for ABAP development, inspired by Robert C. Martin's Clean Code. It aims to improve code quality, maintainability, and readability within ABAP environments.

    For a condensed version of these rules, use the Cheat Sheet, which is optimized for printing.

  2. Overview of the ABAP Clean Code Guide

    main

    The ABAP Clean Code guide is an adaptation of Robert C. Martin's Clean Code principles specifically tailored for ABAP development. It provides best practices and rules to improve code quality, maintainability, and readability in ABAP environments.

    For a condensed version of these rules, use the Cheat Sheet, which is optimized for printing.

  3. Overview of Clean ABAP

    main

    Clean ABAP is a code review guide adapted from Robert C. Martin's Clean Code specifically for the ABAP programming language. It provides principles and best practices to improve code quality, maintainability, and readability in ABAP development.

    For a condensed version of these rules, you can use the Cheat Sheet, which is optimized for printing.

  4. Table of Contents for Clean ABAP Guide

    main

    The Clean ABAP guide is organized into several key sections to help developers write high-quality, maintainable ABAP code:

    • Instructions: Getting started, refactoring, and automated checks.
    • Naming: Best practices for descriptive, domain-oriented, and consistent names.
    • Language: Using modern ABAP features, OO principles, and functional constructs.
    • Constants: Avoiding magic numbers and using enumeration classes.
    • Variables: Using inline declarations and preferring REF TO over FIELD-SYMBOL.
    • Tables: Proper table types, avoiding DEFAULT KEY, and efficient reading/looping.
    • Strings: Using correct delimiters (' and |).
    • Booleans: Using ABAP_BOOL, ABAP_TRUE, ABAP_FALSE, and XSDBOOL.
    • Conditions: Writing positive conditions and decomposing complex logic.
    • If Statements: Avoiding empty branches and preferring CASE over ELSE IF.
    • Regular Expressions: Using simpler methods where possible.
    • Classes: Object-oriented principles, visibility, constructors, and scope.
    • Methods: Calling conventions, parameter types (RETURNING vs EXPORTING), and method bodies.
    • Error Handling: Using exceptions instead of return codes and proper exception classes.
    • Comments: Using code to express intent and using comments to explain 'why'.
    • Formatting: Consistency, readability, and indentation rules.
    • Testing: Principles of testable code, test classes, dependency injection, and assertions.
  5. Clean ABAP Guide Contents

    main

    The Clean ABAP guide provides a comprehensive set of rules and best practices for writing high-quality ABAP code. The guide is organized into the following major sections:

    • How to: Getting started, refactoring legacy code, and automatic checking.
    • Names: Naming conventions for variables, classes, methods, and avoiding noise words.
    • Language: Best practices for object-orientation, functional constructs, and avoiding obsolete elements.
    • Constants: Using constants instead of magic numbers and preferring ENUMs.
    • Variables: Declaration patterns and scope management.
    • Tables: Efficient table handling, types, and access methods.
    • Strings: Using correct delimiters for literals and text assembly.
    • Booleans: Proper use of ABAP_BOOL, ABAP_TRUE, ABAP_FALSE, and XSDBOOL.
    • Conditions & Ifs: Writing positive conditions and managing nesting depth.
    • Regular Expressions: When and how to use regex.
    • Classes: Object-oriented principles, scope, constructors, and inheritance.
    • Methods: Calling conventions, parameter handling, and method body design.
    • Error Handling: Using exceptions, return codes, and proper catching/throwing.
    • Comments: Effective use of comments and ABAP Doc.
    • Formatting: Consistent code layout and indentation.
    • Testing: Principles, test classes, dependency injection, and assertions.
  6. Clean ABAP Guide Overview

    main
    The Clean ABAP guide provides a comprehensive set of principles and best practices for writing maintainable, readable, and high-quality ABAP code. It covers various aspects of development including naming conventions, language usage, constants, variables, internal tables, strings, boolean logic, conditional statements, regular expressions, object-oriented programming (classes and methods), error handling, comments, formatting, and testing methodologies.
  7. Clean ABAP guide standards and compatibility

    main

    The Clean ABAP guide follows the spirit of Clean Code but includes adaptations specific to the ABAP language (e.g., using CX_STATIC_CHECK for catchable exceptions).

    It is designed to be compatible with:

    • SAP ABAP Programming Guidelines (though deviations are explicitly highlighted).
    • DSAG recommendations for ABAP development (though this guide is often more precise).

    If you disagree with a recommendation, the guide encourages giving it a fair chance, as a core pillar of Clean Code is that the team decides.

  8. Enforce type safety in enumerations

    main

    The primary benefit of enumerations is type safety. You should aim to make the compiler reject invalid values.

    Using Native Enumerated Types

    If using native enumerated types, define method parameters using the enumeration's type. This allows the compiler to catch errors at compile time.

    METHODS log_contains
      IMPORTING
        minimum_severity TYPE /clean/message_severity=>type.

    Valid usage:

    IF log_contains( /clean/message_severity=>warning ).

    Invalid usage (Syntax/Runtime error):

    IF log_contains( 'W' ).
    IF log_contains( CONV /clean/message_severity=>type( 'B' ) ).

    Using the Object Pattern for Type Safety

    If native enumeration cannot be used, you can achieve type safety by requiring a reference to the enumeration class:

    METHODS log_contains
      IMPORTING
        minimum_severity TYPE REF TO /clean/message_severity.
  9. Decompose and Refine Complex Conditions

    main

    To improve readability, avoid long, complex conditional statements. Instead, use one of these two strategies:

    1. Decomposition: Break a complex condition into several basic components stored in descriptive variables.
    2. Refinement: Extract the entire complex condition into its own method. This encapsulates the logic and provides a clear name for the requirement.
    " Decomposition
    DATA(example_provided) = xsdbool( example_a IS NOT INITIAL OR
                                      example_b IS NOT INITIAL ).
    
    DATA(one_example_fits) = xsdbool( applies( example_a ) = abap_true OR
                                      applies( example_b ) = abap_true OR
                                      fits( example_b ) = abap_true ).
    
    IF example_provided = abap_true AND
       one_example_fits = abap_true.
    
    " Refinement
    IF is_provided( example ).
    
    METHOD is_provided.
      DATA(is_filled) = xsdbool( example IS NOT INITIAL ).
      DATA(is_working) = xsdbool( applies( example ) = abap_true OR
                                  fits( example ) = abap_true ).
      result = xsdbool( is_filled = abap_true AND
                        is_working = abap_true ).
    ENDMETHOD.
  10. Compromise on encoding prefixes

    main

    If full removal of prefixes is not feasible, consider these compromises:

    1. Namespace Requirement: You must still use your application's namespace for global objects to avoid conflicts in the global dictionary.
    2. Contextual Application: Avoid encodings in local contexts (method bodies, method parameters, local classes) and only apply them to global objects stored in the global Dictionary namespace.

    Warning: This compromise is only effective if the code is otherwise 'clean' (short methods and meaningful names). In legacy code with long, cryptic functions, prefixes may still serve as a necessary identifier.

  11. Maintain a consistent level of abstraction

    main

    Statements within a method should be at exactly one level of abstraction below the method itself. Do not mix low-level implementation details (like trim or to_upper) with high-level business logic (like publish).

    Correct (Consistent Abstraction):

    METHOD create_and_publish.
      post = create_post( user_input ).
      post->publish( ).
    ENDMETHOD.

    Anti-pattern (Mixed Abstraction):

    METHOD create_and_publish.
      post = NEW blog_post( ).
      DATA(user_name) = trim( to_upper( sy-uname ) ).
      post->set_author( user_name ).
      post->publish( ).
    ENDMETHOD.
    METHOD create_and_publish.
      post = create_post( user_input ).
      post->publish( ).
    ENDMETHOD.