All your ABAP prefixes are belong to us
Prefixes
Prefixing variables in ABAP is a hot topic, and during the years there have been many interesting discussions:
https://blogs.sap.com/2018/04/30/are-30-characters-enough-to-make-your-code-better/
https://blogs.sap.com/2016/02/05/fanning-the-flames-prefixing-variableattribute-names/
https://blogs.sap.com/2009/08/30/nomen-est-omen-abap-naming-conventions/
I find it most important that naming is done in a consistent way, all using prefixes or no prefixes at all.
However, all customers I have worked for recently have prefixing as part of their development guidelines, typically supported by the “Extended Naming Convention for Programs” in Code Inspector/ATC. This blog introduces a new Code Inspector check which can be used for making sure prefixes follow the development guidelines.
abapOpenChecks
abapOpenSource is an open source project which provides extra checks for Code Inspector/ATC, a lot has happened since it was initially released 3 years ago. The number of checks has increased from 26 to 69, and a lot of false positives been removed from the results. All checks have different use cases and vary in quality. I recommend trying it out, the checks are widely configurable, and it is possible to cherry-pick the most useful checks.
All your prefixes
The latest check “Naming Conventions” can check prefixes for variables in ABAP and report the findings to the developer.
When reporting findings, the check reports the expected prefix so the developer will not have to look up the conventions or the type of the variable,
As part of the check configuration, it will by default ignore most of the naming in exception classes, as it sometimes is not possible to have these follow the conventions. Also, special function module signatures are ignored, like conversion exits where the parameters are always INPUT and OUTPUT,
Overall it should report less false positives, and if there are false positives, it is possible to inherit from the check class and implement custom rules or give back to the community via a PR on GitHub.
As always, bug reports and suggestions welcome
"However, all customers I have worked for recently have prefixing as part of their development guidelines"
That's because most guidelines originate from last century when prefixing made sense. Apparently change is hard 🙂
Great blog, useful tools, as always!
IMHO, variable prefixes (aka Hungarian notation) makes refactoring more painful and results into unnecessary noise in git commits.
yeah, but if the customer requires prefixes, I hope to make it a bit easier for the developer to align the code to guidelines after refactoring
walking along coastal path spots a nice beach decides to go investigate along cliff edge if there is a safe way down... Along walks a very friendly fellow who offers me a parachute.
Me: "ummm thanks, but I think I'll just look for a path down"
Parachute person: "but we always parachute down to this beach"
Me : "has anyone ever tried walking down?"
Parachute person: "but it's not allowed!"
Me: "why?"
Parachute person: hands over 90 page beach exploring manual printed in 1993.
Me: "but this is over 20 years old! Why are you doing this?"
Parachute person: "hey, it's not me you have to ask mate! You'll have to speak to the technical architects!"
Me: "sigh, ok gimme the darn parachute..."
And a very nice parachute it was! ?
This is very timely as just this morning I got an email with the note that I need to add prefix "C_" to these constants in my program:
This is according to the internal "ABAP guidelines" that don't even exist in any documented form and I'm guessing are just passed from generation to generation as some kind of a folks tale.
I'm still having hard time parting with my LV_s and ITAB_s. Once I tried to use the descriptive name like "orders" but then it did not go well because apparently SAP already got dibs on it. 🙂 Fool me once.
But when we already have constants like "space" or "abap_true" what's the point prefixing our own?
DSAG ABAP guidelines moved on as well:
https://blogs.sap.com/2015/09/22/hungarian-beginners-course-a-polemic-scripture-against-hungarian-notation/
Not just DSAG, but help.sap.com. One of my clients recently updated their standards with the usual lv_ lt_ nonsense (who, me , biased?). I posted on an internal forum that this is inconsistent with DSAG's latest recommendations and SAP's own guidelines. I added some explanation as to why so many prefixes are simply not needed and may even hinder readability.
The standards "owner" and his team responded, and, after I showed them one of my programs without certain prefixes, they're changing the requirements.
Some people, when you talk about prefixes, think you're abandoning all of them. This is not the case. It's only about getting rid of indicators of variable type, not of use. Nowadays, there should be very very few global variables, so it makes sense to state that a non-prefixed variable is local. But global variables do need to be indicated as such.
I see your point about constants, but I'll continue to use c_. I think it's useful to know that a constant at sight. SPACE is part of the abap language, but abap_false and abap_true are pretty much there as well. Hmm... you could really obfusticate a program by defining your own abap_false to be 'X' and abap_true to be ' '.
I learned to cherish supposedly superfluous prefixes like lv_ lt_ and so on whilst maintaining spaghetti-code from the dark ages. One thing I never understood, though, is, why a lot of people use the prefix <fs_ for field-symbols... Has the syntax ever been different than nowadays, i.e. did field-symbols not have angle brackets 50 years ago? °-°
You evil genious, you 😛
I have a theory about <fs_. It also explains why some people use f_ to prefix their Form names. However, it might offend some practitioners so I won't share it. Suffice to say it may be connected to the question, 'Do you still have the boxes the computer came in?'
Forget prefix, I've seen quite a few of <fs> names, literally. I suspect those were just copy-pasted from Help examples or from the interwebs. I might have done the same myself but only the first few times I've ever used field symbols many years ago. Much to my relief, that system no longer exists, so no one can see that horror. 🙂
I believe even DSAG guidelines still suggest to use S_ and P_ for selection options and parameters. And there is I_, E_ for import/export and such. There are times when a prefix makes sense and is useful.
Although I'm in favor of keeping this as a guideline and not enforcing strictly as a standard.
they do
I refer you to my previous comment.
S_, P_, I and E_ etc. are indicators of use. I'm a fan of those. They're also special cases of global variables. Global variables should have a g_ prefix. Then hunted down and destroyed as much as possible and never refered to within, e.g. local methods.
Dear Jelena.
In blog you linked Ralf reasons, that prefixes indicating usage should stay. So Importing is a read only parameter therefore i_ is meaningful. I think that constant is the same case. I've switched to non-prefixing and meaningful naming, but I still struggle with c_. When I see c_ (or co_, or whatever) in code, I immediately know, that this element will not change the logic of code, no matter what happened before (because it's a constant). It's very important. Equally important is to know, that i_var (importing) comes from the outside of method. It tells a lot about logic.
Regarding constants, see my recent submission to ABAP Gore thread. If we only look at the prefix, we don't "know", we just "assume". 🙂
If we look at name of function/method, we just assume it does what it says.
Many times I've seen things you've posted. I also saw methods/functions that do things exactly opposite to what their names suggest :/. There is really no efficient tool against sloppy developers (electric chair maybe..).
I could assume that constant is a constant and r_sth is a returning parameter, or I can just check it. Once checked, I don't have to remember which element was a variable and which was constant. Therefore if code is longer than 30 lines, I still find it useful to have constants distinguished.
Lucky me. I'm responsible for the guidelines and Code Inspector Checks (ATC) in my company 🙂