There’s nothing worse than seeing code that abuses variables. They’re so delicate, and yet they’re treated so badly. Poor things. And to those who have to read them. The worst way to treat a variable is to make it global. It’s hard to believe, but in 2025 this crime continues to plague our systems. Well, here’s a way to show them some love.
Those who work in SAP think it’s normal for everything to be represented by obscure codes that mean nothing. But it doesn’t have to be this way. Stop it! Create human-readable codes please.
I once wanted to test a class whose constructor took several parameters, each requiring an instance of a different interface. These instances weren’t easy to create and weren’t relevant to the test. After some experimenting, I found a way to work around the problem.
A quick reminder. I thought this was obvious but I keep seeing IF statements that explicitly test the result of a boolean method against ABAP_TRUE or using INITIAL. There’s no need! ABAP is clever in this regard.
It’s great to find peers who are equally interested in improving and evolving, not just as a programmer but also as a human being. I recently found one.
Remember how with CALL FUNCTION IN UPDATE TASK you could delay some actions until the moment of a COMMIT?
The FILTER function is new and still relatively unknown. I will give you an example of how it can be used.
Did you know that you can set a starting point for ATC and, thanks to that, be able to run ATC in legacy code?
When a porcelain object breaks in Japan, sometimes instead of throwing it away, they mend it. But they don’t mend it just any old way; they mend it with gold. This technique is called Kintsugi.
It is a common practice in ABAP to use MODIFY instead of INSERT and UPDATE. Do you do it too? Tell me why. Is it laziness? Is it fear? Is it just a matter of “whatever”? Or is it more like “screw it”?
The broken window theory says that if a window in a building is broken and not repaired quickly, people will be tempted to throw stones and break the other windows.
Sometimes it’s useful to look at two areas of the code at the same time. If the areas are in different classes, just open them both. But what if they’re in the same class? For example, if you want to make a method inspired by or related to another.
In SAP it’s normal to have tables in the database with a NAME field and another NAME_SEARCH which is filled in with exactly the same thing as NAME but in upper case.
Then, when you want to do case-insensitive searches you use NAME_SEARCH. You don’t need to do this anymore.
In the ABAP world, the rule is to do it once and never touch it again. Once done, forever frozen. What nonsense.
