When we learn ABAP, we are taught a series of rules on how to name variables. Not everyone uses the same rules but, still, some strict rules are shared between many people:

• Local variables must start with L: L_BUKRS;

• Global variables must start with G: G_MODE;

• Internal tables must have T_: LT_MARA;

• Structures must have S_: LS_MARA;

• Object references must have R_: R_CUSTOMER;

• input parameters must start with I, output with O, changing with C and returning with R.

• And the most stupid of all, field-symbols must start with FS_: <FS_MARA>.

In the early XXI century those rules made some sense (except for the field-symbols on, which was, and still is, as stupid as writing ‘pencil’ in all our pencils). Today they don’t make much sense anymore. Let me explain.

My own naming rules have changed over time. For instance, if global variables start with G_, there is no considerable advantage in using L_ to identify local variables: if they don’t start with G_, they must be local. There goes one rule.

Things get trickier when we start to program in ABAP OO because, technically, global variables of a class are not really global variables but rather class attributes. There goes another rule.

Class references and deep structures can encapsulate distinct complex data that involve tables, structures, other class references and so on. Does it make sense to name all those variables R_ prefix when, potentially they all represent internal tables? If we follow this logic, the great majority of the other rules also falls apart.

In the end, the only rule that still makes sense is the one that allows us to distinguish input, ouput and changing parameters.

Recently, Sérgio Fraga showed me this article that takes these ideas even further, and suggests some interesting alternatives.

Shortly, that article proposes that the name should no longer:

• distinguishe global from local;

• expose that data type (struture, internal table, etc.);

• expose technical names (LT_MARA);

And should instead stay limited to:

• describe its function (CUSTOMER);

• distinguish singular from plural (LOOP AT CUSTOMERS INTO CUSTOMER);

• distinguish parameter variables with I_, O_, C_ e R_.

And I think he is absolutely right.

It’s hard to change something that rooted. And this specific matter will never gather consensus. For the community’s benefit, though, it would be important if we all stop for a while to think about the damn names we are giving our variables. The world has evolved. Let us leave ITBL and WA_KNA1 behind…

Thank you Diogo Simões for the translation.

Thank you Stephen Lock for the photo.

Greetings from Abapinho.