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.
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.
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. (Learn more about Scrum and SAP here.)
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, we gave a presentation on our Clean ABAP repository in the ecosystem’s regular sessions. The participation was overwhelming, with several hundred participants from across SAP. We repeated the session in January 2019, as part of SAP’s annual internal developer conference DKOM. This time, our session was the biggest non-main stage session at the time.
Previously, SAP propagated code style guides either top-down from management or high-level architects to developers, or inside-out from language developers to application developers. We made a point that our guide was from coder to coder at eye level, not motivated by management key performance indicators (KPIs) but purely opt-in, and that we wanted to advance clean ABAP with an interactive community.
The positive feedback encouraged Klaus and Florian to take the next step in May 2019 and make clean ABAP open-source. There was no point in keeping clean ABAP internal; we wanted to share our knowledge with partners and customers. The Clean ABAP repository turned into SAP’s first-ever non-code project to be published as open source.
Writing a book about clean ABAP was an option that had always been on the table. But first, we wanted to lay the groundwork for an interactive community that not only consumed, but actively discussed and developed, best practices further. Now that this community has been achieved, we think it is a good idea to follow up with a book that goes more into detail than the intentionally brief open-source repository.
Editor’s note: This post has been adapted from a section of the book Clean ABAP: A Style Guide for Developers by Klaus Haeuptle, Florian Hoffmann, Rodrigo Jordão, Michel Martin, Anagha Ravinarayan, and Kai Westerholz.
Comments