Why Clean ABAP – A foundation for improvements
Why Clean ABAP – A foundation for improvements
The main benefits of having a common understanding of a code style in a given programming language are improved maintainability, readability and testability. But there are also many other benefits and new possibilities, which this blog explores in more detail:
- Why have a common set of rules? As an organization grows it helps to keep the code base consistent and allows to let the developers focus on the important aspects. There will be less conflicts about basics (e.g. formatting) due to a standard code style.
- Fostering the principle of optimizing code for the reader: Given that code will be read far more often than it is written, an important principle for all rules is to optimize for the reader not the writer. Therefore the style guide weighs readability higher than using powerful expressions, which let the writer express something concisely, but are later hard to read.
- Consistency of the code base: If the code base is built with the same principles and style guide in mind, it allows engineers to jump into an unfamiliar part of the code and make improvements quickly.
- Improve Developer Experience: Having a consistent style guide creates an ecosystem on its own and allows to improve the developer experience. After the Clean ABAP style guide was published in 2019, the community started to create tooling for improving code reviews, documented code review practices, extended static code checks, developed training formats and made some tooling to automatically correct code. This consistency created the foundation for several InnerSource / open source projects, platform improvements and triggered the exploration of further ideas.
- Scaling an organization: As an organization grows it is important to have a common understanding of the code style. It helps to ramp up new developers more quickly and focus the time on pair programming or code reviews on other aspects.
- Also other roles – not only developers – benefit, e.g. consultants who need to make extensions or SRE (Site Reliability Engineering) teams who need to improve operations.
- The consistency also improves the long-term maintenance since new engineers taking the ownership can understand more quickly and maintain the code.
- The style guide allows to enforce rules with static code checks or even develop automatic corrections. So some discussions do not take place anymore, which allows to focus the developers time on more important aspects.
You can find more details about the Clean ABAP styleguide in the OpenSource repository and in the recently published book. Besides, there has been a podcast published recently. Further resources are:
- Clean ABAP becomes Open Source
- Clean ABAP Slack Channel: #sap-abap-clean-code
- Static Code Checks with CodePal
- Static Code Checks with abaplint
- Code Review Setup and Practices
- Translations to Chinese (中文), Japanese (日本語), German (Deutsch), French (Français) and Spanish (in work)
Subscribe to Newsletter: Collaboration on Improving
If you do not miss an update on Clean ABAP, Clean SAPUI5, test automation, testability and other engineering / craftsmanship / architecture topics, subscribe to the brand new newsletter. The newsletter will not only be used for sharing knowledge, but also offer opportunities for collaboration, building communities and co-creation.
I really like the idea of having a common ground or foundation for developing programs (ABAP or any language really). However, I'm sure you will have some gaps based on the timing of the developments. As our grasp becomes solid and the clean ABAP recommendation change.
Being a very small shop. I can't create (even based on the clean code standards) a standard document for coding. I can say use the clean guidelines, but no code reviews are done. It makes it harder to stay with the foundation or guidelines created. Even for me, as I could easily miss some of them.
Now for any place that does code review, you don't have to convince me. I totally agree. I do see a need to go over them at least yearly to see if there is anything you would like to change for your company.
I agree completely Michelle Crapo !
In fact I agree so much that I've just send my last report to a few colleagues to ask them for a code review. Funny part is, they've replied almost immediately, just to say thanks (and ask for a deadline).
I'm curious to find out how bad I did 😉
That's also my point.
Having no option to prove it makes it hard to stay with it.
And a new guideline is for most of my customers something which will end in refactoring a looooooot of lines again... not sure if they are all willing to do so.
Thanks for promoting this concept and huge thanks to all of the people who participated in writing up the repository.
I'm now making the switch to use clean code for objects going forward. One area that is a struggle to me is the lack of distinction between static and instance variables, global and local.
Many are familiar instantly with
gt_vbak, lt_vbak to quickly identify a global vs local table of sales orders.
How is this addressed with clean code when the suggested naming is just "sales_order_headers"?
Also, how do we avoid the ensuing pain and frustration when one developer uses "sales_order_headers" and another uses "sales_doc_headers"?
Thanks for any suggestions you might have.
In that exact example this might be an actual useful differentiation, if intended: sales_order_header refers to Sales Order, while sales_document_header includes Sales Order and Scheduling Agreements...
Thanks for the feedback! More details and recommendations regarding the prefixes can be found here: https://github.com/SAP/styleguides/blob/main/clean-abap/sub-sections/AvoidEncodings.md More context on the reasoning and past discussions can sometimes also be found in the closed issues.
With ABAP in Eclipse you can see the scope and type also quickly using F2 on the variable.
With the right plugin in ADT you can even see the signature of a method in the implementation section without pressing F2, it also shows how many references there are.
Unfortunately I don't remember which of all my plugins that provides it.
There are different schools of thought on this.
Some people would say that there should be no global variables to begin with. 🙂 Noble pursuit but we all know that's just not realistic in some cases. (Also, refactoring legacy programs to get rid of the global variables can be problematic.)
Before Clean ABAP, DSAG published ABAP Guidelines that suggested to keep a few prefixes and G_ for global was one of them. (I'm firmly against using GT or LT for because the variable type should not be part of the name.) However, years ago I've started omitting G_ prefixes and have not experienced any difficulties working with such programs.
My POV: every program should be split into manageable "modules" (ideally, methods, but routines work too in legacy programs). In those modules, it makes sense to use prefixes for import/export parameters (as DSAG guidelines suggested too). Since the "module" should be short, it's really not that hard to see what are local variables and then it's clear if any global ones are used. (Although we should strive minimizing the use of global variables, even in procedural programs.) The need for prefixes mainly comes from the monolithic programs where definitions are separated from the actual code by 5 pages of code. When we operate with shorter "modules", this need simply goes away organically.
I'd encourage to just try dropping the prefixes and see how it goes. You can always come back but I bet you won't want to. Also, I find that many times developers can't actually explain what is the value gained from using prefixes. "It's easier to see what is global" is not a value. Why do you need to see that and how exactly does it increase productivity / improve quality? That's the question to ask yourself and others. You'd be surprise how many times there is no clear answer to these "why" questions. 🙂
Thanks for that perspective, Jelena Perfiljeva . I am "trying it on" right now and so far so good. The smaller modules with limited scrolling is definitely making it much easier to understand. That's one of the things I love about clean abap is it goes hand in hand with better development practices.
Thanks for sharing, Klaus! We can never have too many blogs on Clean ABAP. 🙂
I agree with you completely that specific rules are easier to enforce and lend themselves to the code review automation. For example, I used to work in a team with a very diverse background. There was a manual code review process and it was frequently a point of disagreement or even conflict. A junior developer might have felt uncomfortable pointing something out to a senior developer. And some items were just open for interpretation and more of a personal preference than a hard rule. (However, you need to appease the approver to get your code moving.)
Even though some complex code or particular solutions still may need manual review, I really would love to do away with this high-friction process for 90% or more of the code. This should be an automated process that does not involve emotional humans. 🙂
We try to follow clean abap, with the only exception of prefixs. We had a long, and sometimes heated discussion about them, and the "prefix"-guys and girls won. Our main issue is all legacy code, the boy-scout-rule is not always easy to follow.
Otherwise we've implemented abapOpenChecks and also run all our code through SonarCloud, it does not catch everything but better than nothing. Also we do manual code review using PRs in AzureDevops, but that's another story.
Something that we've also experimented with, with good result, is to let non-Abap-coders do a code review in parallell with an abap-developer. Then you will get some really interesting feedback.
What is the difference between ABAP Programming Guidelines and Clean ABAP?