SAP ABAP
Clean Code
Project
experience June 2023
BaibaBlumberga
I have seen SAPScripts
10+ years with ABAP Have done some dirty
stuff, that always hunts
you down
Clean code with nice
ABAP is still alive design makes me happy
What is Clean Code?
AS IN BOOKS
Clean code refers to well-
structured, readable, and
maintainable code that follows
established coding principles
and best practices.
AS IN TWITTER
The main point of clean code is
that it should reduce ‘WT*s per
minute’
Why Clean Code
is important?
• Reading and understanding existing code
is a major part of the development
process
• The additional effort invested in writing
clean code during the development phase
yields significant benefits when it comes
to code comprehension and maintenance
Deeply ingrained Our existing coding habits are
deeply rooted and can be
habits resistant to change.
Then Overcoming inertia
Breaking old habits and
forming new ones requires
conscious effort and
why it deliberate practice.
comes so Attention to detail
Clean coding practices
involve paying attention to
small details that may seem
hard....
insignificant or time-
consuming.
The advantages of clean
Lack of immediate code, such as improved
maintainability and
benefits readability, may not be
immediately apparent
Steps closer to Clean Code
Mindset of continuous improvement
Steps
Discipline and self-awareness
with
Motivation by understanding the long-term benefits
your self
Continues learning
Get the team on board
Steps Always leave the code a little cleaner than you found it
within a Building clean island
team Set specific goals
Talk about code
Clarity and Intent
Scalability and Flexibility
We take Collaboration and Communication
design
phase Prevent anti-pattern early
seriously
Testing
Main Diagrams we use
Use case Sequence Entity Relation
Class diagram
diagram diagram diagram
SOLID Principles in Clean Code
Development
Each class should have a single responsibility
Single Responsibility Principle or purpose
A class should be open for extension but
Open/Closed Principle closed for modification
A subclass should follow the same semantics
Liskov Substitution Principle of its superclass and be able to replace it
without breaking its contract
Clients should depend on client-specific
Interface Segregation Principle interfaces with only the set of operations they
require
Depend on the abstract representation of
Dependency Inversion Principle underlying resources, not on their concrete
implementations
Class > Function
Module
• If FM needed wrap it in method
• Make sure one method does one thing
• For example, usage of same BAPI for
different use cases leads to several
methods
• Create_entity( )
• Update_entity( )
• Delete_entity( )
Naming - One reads code more than writes
Make sure names are Descriptive and Intention-Revealing
• DON’T use ls_vbak, lt_hrp1000 etc
Drop noise making prefixes
• ls_sales_order → sales_order
• lt_sales_order -> sales_orders
Avoid ambiguity and misleading name
• Be extra careful with abbreviations
Favor readability over cleverness
• Prioritize code that is easy to read and understand, even if it means using slightly longer
or more explicit name
• As little as possible – code should be self-
explanatory
• Explain "Why," not "What“
Comments • Keep comments up to date
• Avoid leaving commented-out code
• Use ABAP-Docs for public methods
Next step - Unit Tests
Consider in Ensure critical
estimates - time code paths are
consuming tested
Use to gain code
Keep Unit Tests up
refactoring
to date
confidence
If possible, use test
driven
development
Where to start
1 2 3 4 5 6 7
Talk about Establish Build clean Break down Eliminate Refactor and Continue to
clean code naming islands complex code duplicated improve learn
within team conventions code continuously
Clean ABAP - SAP/styleguides - GitHub
Technical Debt
What it is? What are consequences?
• Impact on system performance, code
• The cumulative consequences maintainability, disturbed future
• of shortcuts enhancements
• trade-offs • Increased complexity and decreased
code readability
• suboptimal design decisions
• Higher risk of system failures, bugs, and
security vulnerabilities
• It represents the additional work and • Longer development cycles and
costs incurred when code quality is increased maintenance efforts
compromised
• Limited scalability and difficulties in
adapting to evolving business needs
Don’t break
under business
pressure
Thank You
Question?
Comments?
