Clean ABAP

A Style Guide for Developers

Klaus Haeuptle, Florian Hoffmann, Rodrigo Jordão, Michel Martin, Anagha Ravinarayan, Kai Westerholz

• Publisher: SAP PRESS
• Year: 2020
• Print ISBN: 9781493220267
• eBook ISBN: 9781493220274
• Edition: 1
• Topic: Computer Science
• Subtopic: Computer Science General
• Index: Computer Science

ABAP developers, are you looking to clean up your code? Then pick up this official companion to the Clean ABAP GitHub repository. This book is brimming with best practices, straight from the experts, to help you write effective ABAP code. Start by learning when to apply each clean ABAP practice. Then, dive into detailed code examples and explanations for using classes, methods, names, variables, internal tables, and more. From writing code to troubleshooting and testing, this is your complete style guide! In this book, you'll learn about: a. Clean ABAP Concepts
What is clean ABAP and why is it important to write clean code? Understand clean ABAP concepts with insight from the experts, including special considerations for legacy code and performance. b. Best Practices
Walk through the what, why, and how behind clean ABAP best practices. Learn to improve your code, including using classes and interfaces appropriately, handling method design and control flow, designing and running unit tests, and much more. c. Practical Examples
See clean ABAP practices in action! Improve your understanding of how to write effective code. Use detailed examples for each best practice that demonstrate the difference between clean and messy code. Highlights include: 1) Classes and interfaces
2) Methods
3) Names
4) Variables and literals
5) Internal tables
6) Control flow
7) Comments
8) Formatting
9) Error handling
10) Unit testing
11) Packages

1 Introduction

Writing cleaner code is an easy way to boost the quality and maintainability of your code. You can start doing it anywhere and anytime, with any kind of code and project. The price? Practice, discipline, and patience.

In this chapter, we’ll start our discussion of clean ABAP by defining and describing the importance of code readability in Section 1.1. Then, in Section 1.2, we’ll show you how to get started with clean ABAP. Since you’ll likely inherit and interact with legacy code, in Section 1.3, we’ll describe some basic clean code principles, like the Boy Scout Rule and clean islands. In Section 1.4, you’ll learn how to check code automatically. To round out this introduction, we’ll compare clean ABAP with other coding guides in Section 1.5, and finally, we’ll describe how you can interact with the clean ABAP community in Section 1.6.

1.1 What Is Clean ABAP?

Clean ABAP adopts the principles described in Robert C. Martin’s book, Clean Code, specifically for the ABAP programming language. It expands on selected topics to advance the notion further.

While Martin’s original publication applies to all programming languages, its examples mostly deal with Java. Thus, adopting these principles and code in languages with other properties, such as ABAP, can be quite challenging.

The goal of clean ABAP is to close this gap by providing examples that can be readily consumed by ABAP coders, offering guidelines that point out where ABAPers might need to deviate, and relating clean code topics to other guides for the ABAP language.

In the following sections, we’ll explore a fundamental value of clean ABAP: readability. We’ll also take a look at the story behind clean ABAP.

1.1.1 What Is Readability?

Thankfully, programmers who write good code have always been around, but it was Martin who, in 2008, gave wide attention to the notion that code should not only be correct and efficient, but also readable.

The definition is simple: Code is readable if it can be understood easily and quickly.

For example, a “dirty” statement like t = 42. is hard and time-consuming for the reader to understand. The reader must find out that “t” stands for “timeout,” that the number is a duration in seconds, and that 42 is the default timeout for all operations in this context.

The equivalent clean statement timeout_in_seconds = DEFAULT_TIMEOUT., in comparison, gives all these details readily away at first glance—the code is much more readable.

So, why should we care about readability? Past literature on software mostly dealt with the correctness and resource efficiency of programming languages.

For example, Donald E. Knuth’s The Art of Computer Programming gave us thousands of pages that compare the processing times and memory consumption of algorithms to help you pick the optimal algorithms for your purposes.

Martin made the point that, if resource efficiency was the only aspect that counted, we should all be writing code in first-generation programming languages, like assembler, which are by their very nature languages that enable maximum control over all resources and thus have the greatest potential for optimization.

The reason we don’t use a language like assembler is that those languages are extremely hard to understand. They deal with the lowest level of detail you can possibly have on a computer, such as registers, adders, and interrupts. Seeing the bigger picture in this sea of details is particularly challenging.

As human beings, we tend to think in higher levels of abstractions, such as functions, objects, and interfaces—the reason we invented second-, third-, and fourth-generation programming languages, like ABAP, in the first place.

If understandability is what these languages add, then following Martin’s argument, why is code that we write in these abstract languages so hard to understand?

The point we want to emphasize is that programming languages may enable you to write readable code, but that readability doesn’t emerge on its own in some magical way. You must actively learn how to write clean code, just like traditional authors must learn how to write good English prose.

This leads us to what we gain with readability. We read code a lot more than we write code. We may reread our own code many times over when debugging it or extending it with new features. We also read other developers’ code all the time, in reviews, in support tickets, and when connecting to new components. As a result, every minute we invest in simplifying our code usually pays off several times over on the reading side.

The advantages of readability go way beyond time savings. Readable code is easier to verify and therefore harder to get wrong. You’ll not only be able to debug readable code more quickly, but you’ll have fewer bugs right from the beginning.

Also, the software’s design becomes clearer with smaller individual components. As a consequence, attaching new features is easier because more places exist where new features can be plugged in easily, and many more components can be swapped out with little extra effort.

1.1.2 What’s the Story behind Clean ABAP?

In 2010, three development Scrum teams from the SAP governance, risk, and compliance department, including Florian Hoffmann, started coding the new solution SAP Fraud Management in ABAP. To meet the quarterly release cycle in Scrum mode, we started by attending a training—given by Klaus Haeuptle—that was mostly influenced by clean code.

Although we reached many of our targets in the following years, we found that teams still sported quite distinct ideas about what good ABAP code was supposed to look like. Code reviews sometimes degraded into subjective quarrels over harmless details like whitespace formatting.

In February 2018, we started collecting our best practices for clean ABAP code to learn from each other, create an objective grounding for our code reviews, and onboard new developers more easily. We started with a Wiki page, then moved to an internal GitHub repository as the content grew.

Over the course of 2018, Klaus Haeuptle started an engineering ecosystem, a loose community of hundreds of software developers who wanted to share agile expertise.

In November 2018...

Table of contents

• Dear Reader
• Notes on Usage
• Table of Contents
•   Preface
• 1   Introduction
• 2   The ABAP Language
• 3   Classes and Interfaces
• 4   Methods
• 5   Names
• 6   Variables and Literals
• 7   Internal Tables
• 8   Control Flow
• 9   Comments
• 10   Formatting
• 11   Error Handling
• 12   Unit Testing
• 13   Packages
• 14   How to Implement Clean ABAP
• A   The Authors
• Index
• Service Pages
• Legal Notes