In my current project constants are all over the place, with confusing or wrong names. It’s a mess. I’ve found a way to reorganize and rearrange the constants so that the new code can use pretty constants without messing up the old code, which can continue to use the confusing ones.
There’s nothing worse than seeing people abusing variables. They’re so delicate and yet so badly treated, poor things. Here’s a way to show them some love.
Everyone uses blank lines to better organize their code. But where to use them and how many? Let’s talk about that.
While writing code, you should always keep present how easy it will be to maintain. This is particularly important in data declarations. And so easy to do right.
Picture yourself as a monkey hanging from a tree branch. You want to jump to another branch but it’s so far away that you cannot see it. If you jump you’ll probably fall to the ground. That’s bad.
When ABAP programmers run into a LOOP they like to use it to get as many things done as possible. Even if that LOOP ends up having hundreds or thousands of lines.
ABAP evolves (even though it stood mostly still for too many years). And as it evolves, it leaves behind some commands and syntax constructions which are replaced by better ones.
Besides learning what’s new it is also important to learn what becomes obsolete.
When a program is bad because it has duplicate code, it usually becomes shorter once we rewrite it to make it better. But, if its problem is not being properly structured into several classes and methods, if we rewrite it according to the best practices, it will probably end up longer.
Unfortunately that is not what happens in most of the Z code I have seen in my life as an ABAP programmer. Both IFs and LOOPs tend to grow bigger than anyone can deal with. I recently ran into a LOOP with over 1500 lines.
Please stop. Too many regressions happen because someone forgets to CLEAR or to not CLEAR a variable.
Because…why should they be complex to read? It would only make it harder to maintain in the future.
Just because an IF condition is complex doesn’t mean it has to be complicated.
Ok let’s go slowly on this one.
Picture a scenario in which you have a customizing table with several levels of detail which may or may not be defined:
BUKRS (empresa)
WERKS (plant)
LGORT (depósito)
When one of the fields is empty, we treat it as a wildcard, meaning all values are valid.
How many times in your ABAP consultant life did you have to deal with dumps happening as a consequence of a program trying to insert duplicate lines into an internal table defined with a UNIQUE KEY?
Enough.
I recently started working in a new customer and noticed something they do here which I really liked. Whenever they need to call a remote function module by RFC in another SAP system, they create a local function module with the same name and leave it empty, except for a comment explaining that it is a dummy function for that remote function call. Thanks to this simple trick, one can use the where-used tool to find out where it is being called.
