DISCLAIMER

This post was originally posted on SDN on 30-04-2018. I decided to keep some of my posts here too.

In my opinion – yes, significantly.

Rewind. Let’s start from the beginning.

After getting the information about the new edition of M. Fowler’s “Refactoring” I started to think about refactoring process in the ABAP world and which technique I would select as a winner in an almost never-ending run in making your code cleaner and more readable.

I got back in time when I was entering the mysterious, a little bit closed and unreachable ABAP environment. I was a Java programmer, lucky enough to work in a company with a SAP system. In Java, I was coding mostly Swing apps. I felt good to name my variables like “mainWindowHeader” or “currentTime” or “username”. I was reading other’s code and I was understanding it.

Then, when I was entering the ABAP world, I felt like being suddenly parachuted into a country, where people speak few words in English, but the rest of their words is very hard to understand, not to mention pronunciation. My cognitive shock was big – from object-oriented Java constructs to report’s hell with plenty of includes, function modules, subroutine pools, global variables (and a lot of pseudo object-orientation, but this is the topic for another story). The very first problems to solve in my work were supporting tasks and corrections in some reports/function modules.

What was common to every piece of code I’ve seen was variables “chg_kstsn_uzeit”, “howd_maknr”, “cruname”, “br_pernr”, “kur_btrtl”, “old_belnr”, “l_dbblg” – does it make sense to you?

If yes – great, you’re an experienced developer in SAP modules. But if you stop thinking about your experience in SAP, is it really the best you can to name things? And – what is the most important – why still so much ABAP code is written with variables named like entered by my cat having fun stepping on the keyboard?

The first answer – maybe the authors were like me, a young programmer used to see a lot of that code, thinking that this is how the stuff works in this very strange ABAP world. Yes, I got used to such style of coding, I started to do it in the same way and it took me a while to see and understand the difference. Of course, I read a lot of books, but – as a rookie – I was concentrated on digging into the guts of the language, not the style and readability. Maybe I used to think, that complicated code is so goooood and advanced and pro but I’m too ashamed to admit it today…[veil of silence]

Getting back to our BRTFL, ADASE, XCDER and other – they mostly come from the data dictionary where we have plenty of database tables with all these 5 letter long column names. They are then used in structures and other DDIC artifacts, finally ending in the code in various flavors – prefixed, as a part of the variable name and so on. Is it OK?

In my opinion – no. It’s something that really hurt. You encode your code variables using another “language” which you (currently) understand.

Consider the example:

IF ( p0001-btrtl = 'AZW3' AND p0001-abkrs = 'ZW').
  schedule_payment( v_pernr ).

  IF ( vcr_uzeit > '160000' ).
    schedule_report( v_gsber ).
  ENDIF.
ENDIF.

And now this:

IF ( personnel_subarea = 'AZW3' AND payroll_area = 'ZW').
  schedule_payment( personnel_number ).

  IF ( reported_time > '160000' ).
    schedule_report( business_area ).
  ENDIF.
ENDIF.

Which one immediately tell you a story? Which one doesn’t need any, even minimal mental “decoding” of the variables? Which one is more readable by ANY developer?

And when you go even further in refactoring, adding more meaningful constants and small changes…

IF ( personnel_subarea = security_employees AND payroll_area = weekly_paid ).
  schedule_payment_for( selected_personnel_number ).

  IF ( reported_time < reporting_final_time ).
    schedule_payment_report_for( selected_business_area ).
  ENDIF.
ENDIF.

…you can read it as a natural language.

Use meaningful, intention-revealing, pronounceable and searchable names without mental mappings and shortcuts. I won’t be covering the techniques and I’m doing it intentionally – if you haven’t read any book about clean code just go ahead for one – I really like “Clean Code” by Robert C.Martin. I treat such books about refactoring and coding techniques as a guide, keep them close and use them very often when I’m in doubt.

Now, there might be voices:

Hey, stop, I do my development in a very specific environment! Maybe the names are not so readable, but they are from the problem domain! They are from the solution domain! We, ABAPers, know the stuff and this actually speeds up the things, we use commonly known language!

Well, in my opinion, this is an old-fashioned approach. From my personal perspective, it worked some years ago but it doesn’t fit now. Why?

Once again I’ll get back in time. When I was starting my IT journey there were people, the majority of ABAPers I know has been working for the same company, year by year developing the code in modules they know. It was really a centralized work; the code was often in hands of the same people year by year. But things have changed – there is more and more work and still not so many people to get it done. Outsourcing started to play a big role. We change work more often, companies want to have all those shining, cutting-edge features and the only constant thing is change. We switch the context very often. Even if I’m specialized in SAP HCM during my “support” path of career I was fixing the code in MM, CO, FI, TM, PS and several others I can’t recall now. And of course the whole line of HR – PA, PM, OM, PD, PT, PY etc. and SAP Gateway. I don’t have to be an expert in the specific module to get my work done with the assistance of a consultant and when someone has asked me to change the ALV headers in some report or check if the algorithm for a cost area is making the right approximation, unclear names are really not helping.

Next thing related to our memory – even if I’m good at my module now, I can be assigned to other tasks and really forget some of the stuff. After 2 years I could not remember what was that GBRTL. Not to mention that SAP tables can be really huge and memorize all 34 fields seems odd. Multiply this by the number of tables in the modules and you will get a pretty huge number of fields.

Several years ago I had a talk with a developer about the code he wrote and we were working on; during this talk, he explained me his code and what was noticeable – he was using names from the dictionary because he wanted to quickly recognize (due his knowledge in the specific area) that this text field is, for example, 30 characters long. It was easier for him to process them later for an ALV list. Yes, it might work for you, but still, the name of the variable is not for the type. Its type is in the data or type declaration. If you remember all types and its specifications, then your IDE will tell you that this is your favorite BETRG or other:

Not to mention, that if you follow good techniques, the variables are so close to their usage that you can glance at the declaration easily (reports with 22 INCLUDES, 89 global variables is the topic for another story).

Now, do you see what is common in the above arguments? YOU – as a reference for the code. You as an expert, you as a programmer, you as the owner of the code. But now WE should be the most important. We as a team, we as collaborators, we as colleagues who left our code for others. We have now ABAP in Eclipse, we can store it using Git, we do code reviews, continuous integration, unit testing. Of course, team-oriented and clean code existed even when I was playing on my Amiga, but I think that things have significantly changed last 10-15 years – towards sharing parts of the code with various intentions, even in the ABAP world (which sometimes seems to me a little bit behind the concepts and ideas circulating in the other programming language universes).

So, use wisely your 30 characters – it is a rather small number, having in mind that ABAP is case-insensitive and you have to use a separator for different words. Think about the essence of your variable, its core, its identity. These 30 characters could really make your code better, refactor them always if you think it might help to understand the code. ABAP is a really powerful language for declaring things and actually it might be a good topic for another article – hints about using its features for cleaner code.

Finally – why variable names are number on my list for readable ABAP? Frankly speaking, they are the most important thing for other languages I use. But in ABAP they are extremely important – you can write a quite big piece of software using REPORT and its events, structured with basic subroutines and reusing few existing function modules and classes, because the language offers a lot of statements for processing data. Variable names are really important for ease of understanding what the heck this code is doing. Of course, other names (methods, classes, functions and so on) are also important, but I wanted to pick my very first on the list.

In this busy, advanced times, it is vital to make things simpler. I believe that any colleague who has to analyze your masterpiece algorithm, correct it or review, will definitely appreciate readable language other than MTTAS, QWDER, G_WGVBH and other ZXCSDQEW.

BYEBYE