Let's step into the Unknown, the realm of chaos. But you are not alone anymore. In the land of illusions we are many, and many we are lost. Ok, I think I made my point, a bit too overly dramatic. But to be honest, there is nothing more frustrating in SAP than naming conventions (or, better said, the lack of them).
What created the naming confusion in SAP was the legacy code. It remained basically untouched and un-refactored for so many decades that now it’s just an all-you-can-eat buffet. You find everything there, from old code, commented code line, multiple language comments, 1000+ lines functions and so on and so forth.
I don't want to say that there are no conventions at all. But throughout all SAP developments, the consistency is scarce. Once such that we all know is the prefix of variables. Namings as WA_XXX for work areas (or structures) or the classic prefixes LT (local table), GS (global structure) and, when the object-oriented came on the scene, LO/GO (local/global object) is a funny rule that is unique in ABAP programming.
There were and still are limitations that make it not so easy to stick to a certain small list of rules that everyone is happy to adhere to. For instance, a lot of the practices are derived based on how the Data Dictionary and SAP Objects are created. For example, the structure fields are character limited. The name of the classes, same story. This rule applies throughout the whole SAP environment. We don't have the luxury of JavaScript to write 256 character long names. What we have is the fact that all these objects were initially created in German, so a lot of the abbreviations don't make any sense in English. Just to give you an example: VTWEG - Vertriebsweg, KUNAG - Kunde Auftraggeber, VKORG - Verkaufsorganisation ... and I will stop here before the dormant Stasi agents think I am summoning them.
Another point worth mentioning, that contributes to this chaos, is that each company tries to define its own set of rules and guidelines. SAP was not offering clear and concise rules for everyone to follow. There was no higher authority. I appreciate that in the last years they started to release guidelines and get more involved in this topic. But before, it was the Wild West. With each project I worked on, I could see a rule. The rule that there are no rules. No clear consensus.
What are naming conventions in the first place?
Probably this should have been the first point to start with. But you already know, I find it more refreshing to complain first :D
Naming conventions are a set of rules, agreed by developers, in an industry, on how to make their code more readable. Or I should just drop the "in an industry". Nowadays, there are so many programming languages that it makes the life of people migrating from one language to another a living hell. We should be aware that a developer coming from a different programming language needs to adapt fast to read and write code in the new one.
Aaand that's it. Should be nothing more. But you see, this leaves a lot of space for debating or ... imposing. And by imposing, I mean the endless teaching on how one should write their code.
Some thoughts for SAP
Clean code and clear naming conventions means no surprises. A normal day for a programmer that sits for the first time in front of someone else's code should be: "Yep, yep. Aha. Ah! yes. That's pretty cool." and so on. Not the classic "What the f*** is that? What does LST_BZIRK_T mean?"
When we write code in ABAP we already start with some disadvantage. Variables are not case-sensitive, and the pretty painter (code formatter) lets you only have your code either uppercase or lowercase. You can say bye-bye to the camel case (although in CDS Views this works). The only viable option, that is more or less applied already, is the snake case (using underscore).
Let's talk about day-to-day objects in SAP and how we could improve them.
Data Dictionary Objects
I know there is a huge problem with the length of the objects. For example, the length of the field names cannot exceed 30 characters or database tables name can have only 15. Oftentimes this is enough, but when it isn't, use abbreviations. And please, not invented ones. Just google the correct abbreviation.
Names should make clear what the database will hold or what the field represents. SAP already pushes new trends with S/4 HANA. Probably, in the future, we will not even need to manually create custom dictionary objects. CBOs and CDS Views will be the norm. The trend in CDS Views is already to use full wordly field names so that we can finally ditch out the COBOL like 5 character names.
Reports / Functions / Performs
As advice (not only from me but SAP as well), try not to use them at all. Sooner or later they will become obsolete. I already worked on projects where we weren't allowed to create new ones.
Classes
After the namespace, either use CL, IF or CX. The name of the class should be a noun and describe the object that it maintains. If possible, try not to use abbreviations. We will keep those mostly for the type of the class. For example, utility classes end with UTIL or service classes end with SRV.
For attributes, the convention is to start them with M and proceeded by the type of the attribute (table, structure, flag, variable ...).
Methods should describe an action, something that is happening. It often contains a verb (or should always contain one). GET and SET methods access private member attributes, while READ should be used only for selecting data from the database layer. If a method returns a boolean value, start the method with IS/ARE
IF is_flight_scheduled( iv_connid = iv_connid
iv_carrid = iv_carrid
iv_fldate = sy-date
).
"Create new flight
ENDIF.
Packages
In a custom project, I like to have a clear hierarchy and structure my objects accordingly. I like to start with a Super Package ZSP that contains multiple Main Packages ZMP based on each development area (for example, ZMP_SD or ZMP_MM). Each main package contains its own development packages ZDP based on the type of function of the development(UI, Data Agent, API and so on)
Others ...
Variable/Constant prefixes (as LT_, GS_, MV_, C_) are something that you will always stumble upon. Most ABAP programmers have this embedded into their way of coding, our "conditioning". We will have a horrible time changing that. Though I like the idea to use clearly named variables (for example, instead of ls_item, use items).
Comments
In a well-written application, comments should not even exist. A comment means something is not clear in your code. Though, I am aware, in real-world situations, the logic can get really complex, and some additional explanation is needed.
When commenting, use information that is helpful. Don’t state the obvious, don’t add comments in other languages, don’t make “funny” comments. Yeah, it’s funny until it isn’t anymore. Then it’s just clutter and annoyance.
For example, don't write as below.
Final Words
I know it will always depend on the Developer Guidelines of the company or client to write your code. But these guidelines are created by people. And if people realize how much naming clearly objects influence projects, they will start paying more attention to them. But that is not all. I will even say something that I might regret later. Before understandability, consistency is of utter importance.
While writing this article, I realized I could end up writing pages of rules that look good on paper but will have a hard time being applied. I will just contribute to the already overwhelming number of developers trying to impose their writing style. That was not my intention. Lastly, I want you to just keep something in mind. When you start a project, write code for which you don't need additional comments. Think about it as writing a story. Let the code speak for itself.
Comments