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.

Data entered by the user is one of the main vulnerabilities of a programme.

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.

Before the modernization of ABAP in 7.40, a table lookup required an auxiliary variable and at least 4 lines of code.

For many years, when confronted with ABAP OO, most ABAPers I talked to, acknowledged that OO is great for most languages but never saw any real advantage in adopting it for ABAP. So they carry on using FORMs, INCLUDEs and CALL FUNCTIONs. The standard SAP code sets the example by trying to make something work while breaking every possible programming best practice.

No, ABAP will never have the NOT operator.

Abapinho hasn’t been talking a lot about 7.40 because most of the new possibilities have already been widely discussed in other sites and we don’t want to reinvent the wheel. But, here and there, I find small useful jewels which seem to still be under the radar. This is one of them.