Etiqueta > style
Supported by

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.

Best practices
Thou shalt use command TABLES only when unavoidable

Using SELECT-OPTIONS is one of the very few reasons for using TABLES. For all other cases, explicitly declare a local variable for the equivalent structure. TABLES basically creates obscure global variables which increase ambiguity in the code. And global variables should be avoided anyway.

Best practices
Thou shalt use FIELD-SYMBOLs instead of working areas

READ TABLE itbl ASSIGNING is always faster than READ TABLE itbl INTO wa.
Besides, when making changes to internal tables, not only it doesn’t require the explicit MODIFY but it also does away with the auxiliary TABIX variable.
The only situation in which a working area is better is when adding new lines to an internal table.
Some people contend that working areas should still be used when no changes are to be made to the data. This is still slower, but visually can be more intuitive.

Packages 2.0

SAP R/3 repository is a wonderful thing. A vast warehouse of data elements, structures, tables and much more, readily available to one and all. As developers, it is extremely convenient to quickly pick these elements and pull them into our programs as necessity conveys, while our string of thought remains virtually uninterrupted.
Well, not all is sunshine and roses. If you are not careful with the mushrooms you pick you might get a poisoned one.

Ler o resto do artigo! »

Best practices
Thou shalt group related parts together

Sometimes you find an IMPORT in the code but you have no idea where the corresponding EXPORT is. When communication is needed between programs, it should be done using a pair of methods belonging to the same class. This way, when we run into one, we’ll always know where the other one is.
Anyway, try to use EXPORT/IMPORT only when unavoidable. If possible, use static class variables instead.

Best practices
Thou shalt avoid dynamic messages

When you need to send a dynamic message by parameter, make sure you still use the MESSAGE command, so that the “where-used” doesn’t loose track of it. When you do MESSAGE E001 INTO V_DUMMY, the message details become available in the system variables: SY-MSGNO, SY-MSGTY, etc.
Also, message texts should never be hardcoded, they should always be defined in SE91.
https://abapinho.com/2009/09/evitar-mensagens-dinamicas/ (portuguese)

Best practices
Thou shalt not use direct code in user-exits

All code to be put in user-exits (BADIs, enhancements, SMOD, etc.) should be encapsulated.

  • It’s common for an user-exit to include multiple independent parts. Each of these parts should be encapsulated in its own method. Even if it is only one line;
  • This should apply to both new implementations and changes to existing code;
  • A change to existing code should always be seen as an opportunity to organize existing code into methods, since it will have to be tested again anyway;
  • If a class associated to the respective user-exit still doesn’t exist, one should be created;
  • The name of the class should be clearly related to the name of the user-exit. Ex: for user-exit ZXF01U01 uses class Z3F_CL_ZXF01U01.

https://abapinho.com/2009/03/melhorar-os-melhoramentos/ (in portuguese)

Best practices
Thou shalt not implement in classical processing blocks

Official ABAP Programming Guidelines (page 34): [When a classical processing block is required], you should immediately delegate the execution to a suitable method (see Rule 6.37, No Implementations in Function Modules and Subroutines, and Rule 6.44, No Implementations in Dialog Modules and Event Blocks).

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