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.

Today we’ll try to optimize the code to convert a SELECT into a RANGE

Some years agor I showed how to convert a normal MESSAGE into a typified exception. Meanwhile ABAP evolved a lot and now, since version 7.40, that complex solution is no longer needed.

If you regularly read Abapinho you probably know by now that I can’t live without ABAP Package Concept. Nowadays the first thing I do when starting a new development is creating an encapsulated package to hold all its objects (in the most complex scenarios, I create it as a main package and then create multiple child sub-packages).

I lay here a modest proposal (unlike the original one, mine is not sarcastic) to help organize thing a bit at system level.

My current client’s system is finally being upgraded to 7.50 and, after all these years stuck with the old ABAP, I am now finally able to enjoy the wonders introduced in 7.40.

There are dozens of these wonders and I don’t intend to start making a post on all of them as there is already so much quality information on most of them. Besides, Abapinho always tries to write about something new or, at least, not very known.

But this simple functionality, although not that extraordinary, pleases me: you no longer need to add IS INITIAL in an IF command when the condition is a method returning a boolean.

It happens very often that, while programming, I smell something strange. It’s usually hard to identify it right away. It usually starts like a faint fragrance. But, as I become more aware of it, eventually it starts stinking and I understand where it comes from. Even then it is not immediately clear why that particular thing smells bad.

Since 1998, I hear some ABAPer colleagues saying that it’s not worth encapsulating a particular piece of code in a function or method because it will never be reused again. And then they go to SE38 and create yet another report full of includes.

The idea that you should encapsulate your code for it to be reused by you or by others is one of the biggest misunderstandings of the history of our planet.

In SAP’s world, ABAP code will forever stay wherever you leave it.

On one given day, Manuel did something badly because he was on a rush or didn’t know any better. One year later António is asked to make a small change to it. António spots Manuel’s mess but he doesn’t improve it because, for some reasons, in SAP, changing something which is working, even if it’s badly implemented, is a tabu. Instead, António will add his code to the existing one and forget about it.

This attitude, when adopted by everyone, contributes to an inevitable erosion of the system’s code which, some years later, becomes unmanageable. And still, that’s the rule.

The way I see it, this is wrong and goes against the customer’s best interests. Actually, even if the customer doesn’t want me to modify old code because it’s working… I still do it. Who is he to tell me how to program?

We learn in school that all code should have comments. Then, in real life, we find that not everyone was paying attention to what was said in school. As a consequence, most code is obscure and without proper comments.

I was always careful to comment every relevant step of my code, specially the parts which are obscure or not self-explanatory.

But since I recently read Uncle Bob’s Clean Code , my opinion on this changed. Today I believe that the less comments the better. And yet, I don’t see this as contradictory to what I used to think.

João studies Computer Science at his College where he learns Java, polymorphism, encapsulation and a lot of other programming techniques and best practices. When he graduates, he decides to join a company to work in SAP. At the introduction training which his new company offers, the first thing he learns is how to make a program in ABAP. Here’s how they teach it:

_“Go to transaction SE38, create program ZJOAO and then create includes ZJOAO_TOP, ZJOAO_FRM and ZJOAO_SEL. You declare all variables in _TOP, the selection screen you put in _SEL and all the FORMS must go into FRM. Then write START-OF-SELECTION and under that put all the SELECTs and finally write END-OF-SELECTION and there you show the results in an ALV. It’s that simple. Welcome to ABAP."

This article was written by José Vília:

The Dolly sheep was alive in ABAP and I didn’t know about it.

Having created a class instance, I’d like to share it with another totally independent program to use it as if the instance had been created there.

It’s an ABAP Dolly sheep factory we’re talking about here, people. Serialization in the ABAP world.

We’re all lazy. It’s just human. Programmers are human. We’re often lazy when it comes to the way we program something. And usually being lazy when making a program will result in someone else having more work when maintaining it.

Let he who is free of laziness throw the first rock.

I won’t!

Foreword

When I say that I like to use UML class diagrams to document my code, people think I’m crazy.

Introduction

The UML has gained a bad reputation because people think that, first you make the classes diagram in UML and only then write the program. But that was in 1996, when you the good practices said the first thing to do was the whole technical spec, even if no one really did it.

Nowadays, fortunately, we are no longer ashamed to say that the very act of programming is already in itself a way of drawing.

If you read Abapinho you already know how much I like exception classes. But this is not the only ABAP mechanism for dealing with errors.

There is another one, called ASSERT, which should be used more often.