Etiqueta > style
Supported by

Best practices
Thou shalt modularize, modularize, modularize

Historically ABAP programs tend to grow very loooong. All programming best practices teach us there is not a single advantage in this approach.
If any routine, be it a program, a method, a function or anything else, becomes longer than 200-300 lines, question it and seriously consider refactoring it into several sub-routines.
This has the added advantage of potentially increasing code reuse. But the greatest advantage is encapsulation, isolating variables in their local context, instead of having all of them together, resulting in safer and more readable code.
The Official ABAP Programming Guidelines book advises this in its chapter 2.2 KISS (pages 32-34).

Best practices
Thou shalt reuse, thou shalt not rewrite

If the same piece of code is repeated at least once, question yourself why and try to avoid it by creating a reusable routine.
If there is more than one SELECT for the same table in a program, make sure you can’t merge them into a single one. Sometimes a smart use of RANGEs to unify parameters can avoid the need for multiple SELECTs.
If the same code is used in 2 different programs, don’t repeat the code. Instead, create a class for it which can be shared by both and move the reused code to the common class.

More RANGEs, less SELECTs

Best practices
Thou shalt avoid global variables

The more global variables a program has, the most obscure it becomes. Please avoid them. This is a basic rule of good programming and should always be followed. Even if several variables have to be passed by parameter, it takes slightly more effort but yields a much more readable and safer code.
Exceptions can be made for simple reports which run around a single internal table, which can be declared globally without compromising clarity.

How to ask if the line exists without seeming fashioned

Long ago, you used the expression “groovy, man”. Later came “great, man”. Then there was “cool”. Today you say “awesome”. It’s important not to get confused and not make a fool of yourself. 

And how do you ask an internal table if a line exists exists?

Ler o resto do artigo! »

Best practices

Many times we do READ TABLE itbl or LOOP AT itbl just to do a CHECK SY-SUBRC = 0. In these cases, the actual data read is not needed. For these cases always use TRANSPORTING NO FIELDS. This way is faster and avoids having to declare a target structure.

SELECT-OPTIONS default behavior

Abapinho received a letter.

Mr. Abapinho,

Everybody knows how to set default values in select options using the DEFAULT keyword. What some people may not know is that one can also set the default option, sign and even if allows for intervals or just fixed values.
Ler o resto do artigo! »

Chained exceptions

Today I will teach you how to chain exceptions. It’s a very practical solution to a complicated, not so obvious problem.

Let’s start by describing the problem.

Imagine you are in the application BANANA.
The application is quite complex.
It has three modules: BANANA1, BANANA2 and BANANA3.
Each one has its exception class ZCX_BANANA1, ZCX_BANANA2 and ZCX_BANANA3.
Since the application is in fact well designed, all the exception classes inherit from the same ZCX_BANANA.
Now imagine the following scenario.
You are in the BANANA1 module doing something.
There, you must call a class from the MORANGO module.
Of course, this class launches exceptions of the type ZCX_MORANGO.
This is the context.

You have several options:

Option 1: Declare the external exceptions
The method which calls the MORANGO class declares the exception ZCX_MORANGO in RAISING.
All of the methods which call it must declare it as well.
Henceforth, to the top of the call hierarchy.
It’s a big mess.
Imagine that BANANA must also use classes from the modules ABACATE, LARANJA and UVA.
It will also have to declare the respective exception classes in every method which uses them.
The more complex it is, the more confusing it all becomes.
This is not what we want.
Generally, anyone who does this ends up having to do a CATCH CX_ROOT, which is somewhat unhealthy.
For all of these reasons, option 1 should be avoided.
Except in very simple scenarios.

Option 2: Convert external into internal exceptions
Each BANANA method which invokes MORANGO methods always does TRY CATCH for ZCX_MORANGO and immediately launches an exception of the type ZCX_BANANA.
This even works.
The problem is that, for each exception of MORANGO, there must be an equivalent exception of BANANA.
If it’s just one, everything’s okay.
But in the case of dozens, it becomes silly.
And it’s not very secure.
Each of the exceptions created will have to replicate the specific text of the respective MORANGO exception.
This is not very practical.
This is because if tomorrow someone changes something in MORANGO, then BANANA becomes outdated.
It also tends to generate a large amount of confusion.
For all of these reasons, option 2 should be avoided.
Except in very simple scenarios.

Option 3: Use PREVIOUS to create chained exception
All exception classes have an attribute called PREVIOUS.
This is a reference for each exception class.
When the BANANA method invokes methods of MORANGO it always does TRY CATCH to ZCX_MORANGO.
But it does not launch a specific exception for each exception of MORANGO.
Instead, it always launches the same ZCX_BANANA exception.
But I have assigned the MORANGO exception to the PREVIOUS of the BANANA exception.
Whoever handles all the exceptions at a higher level only has to see whether the PREVIOUS has any content.
If it does, then it presents/saves/processes the exception there as well.
Ideally this should be done in LOOP.
In the event the exception of PREVIOUS has, in turn, another exception in its own PREVIOUS.
This is the best of both worlds:
Future proof code, which does not lose the information of specific exceptions.
For me, this is the best option.

I hope the both problem and the solution I propose are clear.

I leave you now with a simplified implementation of option 3:

    CATCH cx_morango INTO o_exp.
      RAISE EXCEPTION TYPE cx_banana
          previous = o_exp.
CATCH cx_banana INTO o_exp.
    log( o_exp ).
    o_exp = o_exp->previous.

Thank you Clark for the photo.

Greetings from Abapinho.
Ler o resto do artigo! »

Ignore function module exceptions

When calling a function module which returns exceptions you normally give them sequential numbers like this:

    ali = 'To the moon'
    NOT_FOUND = 1
    GOT_LOST  = 2
    OTHERS    = 3.

But Code Inspector may be configured to report a warning if afterwards you are not careful to add an IF or a CASE to look at SY-SUBRC,
Ler o resto do artigo! »

Let’s concatenate

We start with two variables:

DATA word1 TYPE string.
DATA word2 TYPE string.
DATA: phrase TYPE string.

word1 = ‘this’.
word2 = ‘that’.

And we want to concatenate them adding the word “plus” between them and, of course, separate them by space.

Ler o resto do artigo! »

Where is the boolean?

It’s not.

But they – the people who make and remake the ABAP itself – are trying to mend this unfortunate situation.

Look at this new functionality:

Ler o resto do artigo! »


Did you know that you can do a LOOP on an internal table of one type into a structure of a different type?

Ler o resto do artigo! »

Best practices
Thou shalt not use CHECKs directly in user-exits

User-exits (and enhancements) are usually crowded with CHECKs. The tragic consequence is that, if the check fails, nothing else after it will run. Not even the standard code. Always try to correct these. Encapsulating the code inside a routine (ideally a method) is enough to render it harmless.

Best practices
Thou shalt use LIKE LINE OF itbl

When declaring structures which will receive data from an internal table, instead of declaring its type directly, use LIKE LINE OF. This way not only it becomes clear that they are related but also, if you happen to change the type of the internal table, you won’t have to worry about updating the structure’s type.

Best practices
Thou shalt use a constants table

Whenever you feel a constant value can change and you can’t add it as a user parameter, store it in ZCONSTS. This table should never be used directly. Instead, a class like ZCL_CONSTS should be created to properly access it, like shown in this article:
https://abapinho.com/2009/06/constantes/ (portuguese only)

Resist the temptation of using T900 or similar tables for this purpose. It’s true that a lot of people do it. But it’s ugly, durty and besides these tables don’t even have an adequate key because they were not designed with this in mind.

Best practices
Thou shalt build up and adopt toolkits with common tools

Code which is used very often should be made available centrally, if possible under a single package (ex: ZTOOLS) so that it’s easily identified.

  • There is a lot of code already available on the Internet to accomplish several common functions (ex: ABAP2XLSX). Adopt it;
  • For your most common tasks, develop your own tools which you can reuse and add them to the central library;
  • Advertise the existence of that library among your colleagues to avoid that they waste time come up with duplicate code wasting;
  • Whenever you develop specific code which you think can one day be reused somewhere else consider making it more generic and add it to the central library.

About Abapinho
Abapinho runs on WordPress
Articles (RSS) e Comments (RSS).