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.

Most ABAP programmers are like swans. They marry ABAP forever and are eternally faithful.

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.

Did you know that, if you SAP is recent enough, you can use complex ABAP expressions in the middle of SQL commands?

After over 10 year using Wordpress, the world evolved and Abapinho decided it’s time to evolve with it.

Please stop. Too many regressions happen because someone forgets to CLEAR or to not CLEAR a variable.

Legibility is very important in all written text. Except, maybe, in concrete poetry.

As a follow up to the previous post, here are a couple of rules to help you deal with the negative in boolean expressions.

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.

ABAP SQL is becoming more and more interesting and powerful. My latest discovery is the ability to use CASE in SELECT.

My dear friend Sérgio Fraga passed away. Abapinho also belongs to him. Forever. Thank you my friend for everything you were.

RANGEs have interesting properties.

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:

1. BUKRS (empresa)

2. WERKS (plant)

3. 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.