Thou shalt avoid global variables

images/thumbnail.jpg - Thumbnail

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

images/thumbnail.jpg - Thumbnail

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?

Thou shalt use TRANSPORTING NO FIELDS

images/thumbnail.jpg - Thumbnail

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

images/thumbnail.jpg - Thumbnail

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.

Chained exceptions

images/thumbnail.jpg - Thumbnail

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.

Ignore function module exceptions

images/thumbnail.jpg - Thumbnail

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

CALL FUNCTION 'GO_BUT_PLEASE_COME_BACK'
  EXPORTING
    ali = 'To the moon'
  EXCEPTIONS
    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,

Let's concatenate

images/thumbnail.jpg - Thumbnail

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.

Where is the boolean?

images/thumbnail.jpg - Thumbnail

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:

LOOP AT tbl ASSIGNING <line> CASTING

images/thumbnail.jpg - Thumbnail

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

Thou shalt not use CHECKs directly in user-exits

images/thumbnail.jpg - Thumbnail

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.