ABAP Code Naming Conventions – A Rant
Take everything with big pinch of salt
(unless you have high blood pressure in which case do not read this rant, it’ll probably make it worse.)
It is not my intention to offend!
A couple of people have asked me to cross-post this rant to here on SCN. It’s their fault that it’s here. π
Ok, you can probably guess that I’m not the most conventional person. I probably don’t fit the mould of the stereotypical developer either. I’m certainly not what one would call an introvert.
So please take this with the necessary pitch of salt. (especially if you’re one of the people who writes the code naming conventions that I have to follow from time to time )
<rant>
Why on earth does every SAP project I go to insist on such inane naming standards for the code? The SAP editor is a wonderful IDE (caveat I did not say it was the best IDE) that allows you to see the definition of any variable with a simple double click – so why on earth are you so worried that I should prefix all my local variable definitions with an ‘L’? What on earth potential benefit can this have on the code readability? Perhaps it helps if you’re still one of my nemesis developers who are passing all your variables between methods through the use of global variables and/or singletons. Perhaps one needs to look at a piece of code, see lots of L’s and that gives satisfaction? The use of Hungarian Notation in ABAP code seems to be universal, although never it seems implemented in the same way.
Then when I define a structure, I must prefix it with a “S” just so you can be sure that it isn’t actually a table or a single field, or so help me, a woolly mammoth. When I look in the IDE view of the package I am developing, all of these different things are arranged in a tree so you can easily tell one from the other. Again a single double-click can bring me to the definition if it is ever referred to in a piece of code. Perhaps it might save some time looking at a variable definition to see if it is a table, a structure, object reference or a variable – but if I’m in the code, it should be pretty damn obvious! If I’m appending or inserting into it, it’s a table. If I’m referencing a sub-field of it, it’s a structure. If I’m assigning a value to it it’s a variable, if I’m creating an instance of it, it better be an object reference. There again may be cases of my nemeses developers still using tables with header lines and confusing the heck out of me. But I’m hoping that the code inspector might weed at least that out. Sometimes I’m tempted just to create structures containing nothing but tables so that people relying on the Hungarian notation get really confused, but those that realise that the syntax checker might just have mentioned something if I was trying to append to a variable are still cool. π
Searching outside of the SAP world the use of Hungarian Notation within code is not universally disliked, but with such a clear list of disadvantages and such luminaries as Uncle “Bob” Martin and Linus Torvalds against it, you’d have to proclaim yourself a pretty die-hard supporter of “doing it the old way” not to just think a little – “is this really useful? Or is it even potentially bad?”.
Then there comes the requirement that every object should reference the area of use it is intended for. Thus the forth and fifth characters of the object name must be “HR” or “PA” or “XX” or whatever. The use of Positional Notation for implicit metadata about a component is, however not something I’ve seen outside of SAP projects except for the COBOL example given in the linked Wikipedia page. At this point when reading the naming convention guide, I casually check if there is any mention of packages and package hierarchies and hope upon hope, package interfaces. When there isn’t, I sigh again and just bite my tongue again. Because SAP has provided a wonderful way of helping us see what use a component is put to – as every component must belong to a package, and that package can (and should) have an application component defined. And to give even more clarity, the package can have a super-package, thus grouping all like component together, whatever types they are and where ever in their object names they have a ridiculous two character code. The package interface can even tell you if the object is safe for use outside of the package. What a great concept!
So instead of spending time thinking about whether the components we are building are truly reusable, and what the scope of that reuse is. We spend hours checking if we have the first n characters of our our objects correct according to the development standard book.
</rant>
One day someone will be silly enough to let me do it my way, I’ll confuse the bejeebers out of all the guys who’ve only been coding ABAP badly for the last 10 years and the project will potentially fail because I’ll spend my entire time looking for enough of a development team that can understand that following a rigid way of doing things isn’t always the best way to do it…. <sigh>
Disclaimer:
I originally did not post this rant on SCN as I feared it might upset people. And I may yet make changes/remove it if it gets too political. I know lots of people who are quite attached to their development naming conventions and many will argue that they are a good thing. I’m certainly not arguing for a lack of rigour in code, but just that perhaps we could invest the time elsewhere.
I’d like to reiterate, these are my views (and I may have exaggerated them a little here too) and particularly in this case, do not represent the views of the company I work for. All errors, omissions, confusions and misunderstanding are mine. I serious have not set out to offend people, so please if this is offensive to you, let me know and I’ll try to sort it out.
You can find the original post and my other thoughts on my blog at wombling.com
This has tickled me! I couldn't agree more.
Just last week, whilst delivering BPM training to a customer's dev team, we got on to the subject of naming standards in NWDS whilst working with CE and I ended up ranting about this very topic.
My personal pet hate is when you go to SE11 and find a table called "Z_CUSTOM_MARA_TABLE" for example, which gives you no clue at all what it is for, other than it is a table and is probabaly related to material masters. Why?!
Of course it is a table, I know it is a table because it just is and of course it is custom, the Z gives it away! Don't call it a table. Do you save your MS Word documents and call them "Custom Development Stuff Document.docx"?! It's redundant and just a waste of your electricity and my energy!
Being serious for a moment, I'm a firm believer in having guidelines rather than standards, especially when it comes to naming conventions. This is especially important as we see more and more different technologies, IDE's & languages being used in the SAP world. Flexibility FTW! π
Feel better for that...
Your reply reminded me of a blog I once wrote about the naming of constants (shameless plug but it really did π ): Constantinizing the hell out of your ABAPs
Cheers, Roel
That was a good blog too π
Aaah! The overuse of constants, my pet hate. I have even seen code like
CONSTANTS: C_ value 'X'.
Worse still:
CONSTANTS: C_1 VALUE '1',
C_2 VALUE '2'.
Why?????
Because some developers just want to watch the world burn.
Worse:
CONSTANTS: c_movement_type_102 ... VALUE '101'. π―
Really, I have seen this.
In SAP plant maintenance the internal code for an object flagged for deletion is something like "ISRU0076" or something equally meaningful.
I saw a program where the author had not wanted to hard code this, and so he used a constant. And what did he call it?
C_DELETED maybe?
Don't be silly!
It was C_ISRU0076 value "ISRU0076"
Gareth,
absolutely. Spend the time and energy you'd put into building SCI rules and checking the naming standard to teaching the team about how to use exception classes or whatever. have some guidelines and help people to code as well as they can!
Thanks for comment and tweet!
Hi Chris,
Seems like the Aussies are on a blogging spree π Very nice!
I used to be anal about naming conventions until I realized it does not matter...at all!
Somehow in every (large) company there's a developers manual consisting of tens of pages that no developer will ever read and in every one of them is a chapter about naming conventions. It's ok to have guidelines but every developer seems to have their own and that is fine! There's absolutely no point in enforcing them and as you said that energy should be put into useful matters. Better concentrate on having good working code. ABAP developers are creative and stubborn. You should hold them accountable for the quality of their code (robustness, reusability, performance, etc.). How they name their variables is not part of that.
Cheers, Roel
Yep, names should be as clear as you can make them, but it is probably far more important to concentrate on "the quality of their code (robustness, reusability, performance, etc) ".
I fear that in many peoples minds (and also part of the sales pitch that SIs give to potential customers) is that consistency == quality.
Whilst inconsistency in approach and design may well indicate a problem, using the tools (i.e. packages, heirarchies, etc) to their best effect meaning that the list of objects doesn't sort nicely when transports are dumped into a spreadsheet does not.
Thanks for the comment and link to your blog.
Hi Chris, Roel,
Some ten years ago I was also an Naming Conventions addict and even proposed standards ( http://www.sap-press.com/products/Enhancing-the-Quality-of-ABAP-Development.html) that are still being used today. Since then I have come to the conclusion (or rather, some cleverer developers than I am convinced me) that the only important convention should be to make sure that a name describes what it is. The prefixes and suffixes that are being used actually make code less readable.
However, I have experienced that checking if a program is compliant with the naming conventions is often the only kind of quality check that is being performed.
Hi Ben,
Very good point. People doing quality checks should define 'quality' first. I've seen ABAP developments coming back because I used l_ instead of lv_. Completely misses the point of quality checks. Luckily that has been a while. Lately I try to adopt the standards that I see in a client's code as much as possible but I am not dead set on adhering to them. I like the convention that the name of a variable should describe what it is. It does make reading code easier.
Cheers, Roel
The reason why the quality chaps check for lv over l, for example, is that this is something they can control. The actual quality of the program is beyond them. It's exactly the same as you will find in the quality teams who look at project documentation on a validated system; they cannot control the contents, so they have to check the formal aspects.
Thanks for this. As a C/C++ guy (who never ever coded with the hungarian notation), I was surprised when I touched R/3 2.2 ABAP first time. All these strange prefixes ... .
Unfortunately, code quality metrics generated by Code Inspector (SCI) locally and collected centrally solution manager cares much about the hungarians. Many companies offer code quality benchmarks based on SCI rules ...
Without well named P_'s and LS_', several 100s of naming violation warnings quickly generated. And if you'll get paid for "good code" equals to zero SCI erros/warnigs, you'll start liking the hungarians again π
It's certainly a shame that the tooling continues to support this , in my mind, madness.
And again "code quality benchmarks" aye!
The more I have Java and ECMAScript being my bread and butter, (which I certainly predict to be the case) the less I have to worry about the Hungarians π
PS to anyone who is actually from Hungary - that was in no way intended to be a racial slur! That would be the way to get myself into real trouble!
On the other hand, applying some naming convention (and I think Hungarian suffices, nothing more needed) does help others to read and understand your code with minimal effort.
I never assume that the developer coming after me has the same level of skills. There might be developers out there that don't even know you can nest tables in structures in tables in objects in a pointer (field symbol).
In one instance, we had a developer on our project (for about 3 weeks) who didn't use any normal variable, but put everything in field-symbols. If the application would've worked, I would call this impressive. Nevertheless, it was unreadable, non maintainable and it dumped in 95% of the cases. (there were 20 scenarios, and it only worked in one. Which happened to be the unit-test case)
So yes, you can overdo naming conventions, but you can also overdo on the cowboy gunslinging.
Quote from my mentor:
Good code reads like a good book.
My addition:
and I like to recognize the main characters.
Hmm. You do realise that what you're ranting about has possibly evolved (like any standards document) over time to avoid pitfalls and other suchlike mistakes that are often repeated. As in life, anything that evolves tends to do so for a reason, be it good or bad, but mainly good in our environment.
Personally I see no problem with identifying local and global variables, and identify structures and tables specifically. That practice seems to be common among many programming languages, and not just for ABAP.
Trust me, if you visit code that does not adhere to any standards it's hell to make changes to. I've just peer checked some code written offshore. In their defence they were not given the coding standards document, but, as a contractor they should still have adhered to some kind of coding standard, which they seemed not to have done. Needless to say I've sent them the standards doc and asked them to make the necessary changes.
If any business is fanatical about having coding standards, then apart from having peer checks in place (which I'm a fan of) it's also possible to carve these standards (I believe) somehow by configuring the code inspector, so that it pops up if you attempt to create a non-standard variable name, for example. At least that's what I recall from reading the blurb on the code inspector, when it was first announced. Never seen anyone do or use this feature, although colleagues inform me that they have.
I have worked for a few consultancy's and most have very detailed coding standard documents, covering not only ABAP, Smartform and Sapscript, but also Javascript and HTML, especially when in a CRM environment. Sadly many clients fall well short of these qualities. But then I blame SAP for that, for not initially posting a clear and precise document for coding standards, as a guide. Or perhaps they have, now. If they have though, I and many others do not know where it is, and, I know full well from looking at SAP's own code they are not always following it. π
Hi Gary,
which other programming languages have you come across that use Hungarian notation? I have to admit to only really seeing it used today in ABAP. Certainly in the Java and Javascript/ECMAScript I write I don't see it so much.
I'm afraid I have seen SCI set up to enforce lv_name.
I'd like to reiterate, code without naming conventions does not mean code without standards! Things like limiting the number of methods in a class, limiting the number of parameters in a method, using unit tests (if they are actually useful and not there just to pass SCI checks) should help with the quality of code. Just that forcing differentiation with the first two characters of a variable as to its scope and type doesn't in my view actually do anything to help with quality.
Thanks for sharing your views. π
In C and C++ we used to identify our variables with a prefix as well
intCounter
strFirstName
tables are rather clear by the use of the brackets[] (syntax enforced)
In Java, I did this as well. Same as for Pascal and even *gasp* Visual Basic.
In javascript, there is per default no strong typing, so your "hullapalooza" can be an integer, an array, a vector or a class, and it can change over time. Arf!
Try "scheme" if you like unstructured languages. It even allows you to dynamically rewrite your code (the one in execution, not some other code, but actually the one in memory at that particular time)
Hi Gary, your post is nice. I can understand your idea of putting your time to better use instead of using the lame naming conventions. I however, agree with Gary that it is required, although for a different reason.
You see, not all customers have completely converted to the OOPS standards. Most are still living with their age old programs which as per them are running fine, so why should they change? So for most of us ABAP developers here, we need to still go on breaking our heads figuring out why the previous developer has written such a logic and what it should have actually been. With naming conventions, this becomes the ray of hope we hold on to.
Also, naming conventions are useful when you are not in the SAP GUI but need to analyse a list of objects (a very basic example). In such a case, I find my time saved if the developer has used the standard naming conventions set up by the customer. I usually have to do a lot of peer review and go through a lot of review documents where the naming convention saves my day by not forcing me to look into SAP for each and every object.
So, I think it's a necessary evil we or at least I would not mind living with.
Cheers!
Naturally, you don't go converting old programs to a new naming style if they're not being enhanced. That just change for changes sake. But I really don't understand the point you are trying to make.
I don't see how non-OOPs programming requires typing prefixes, because, quite frankly, it doesn't.
I also don't see how typing prefixes help understand how programs work any better than meaningful variable names, correctly scoped. Again, quite frankly, it doesn't.
Naming conventions do not make code easier to read... But "good" naming does.... Coding is essentially the task of naming abstractions.
Prefixing all your code with lt_, iv_ is nonsense In my opinion and clutters the code.
Even SAP's official ABAP Guidelines available from SAP Press states that research shows it's a waste of time that clutters the codebase....
Hey Matthew, Maybe I was not able to explain my pain properly. You see, old programs (or lets just say non-OOP programs) use a lot of global variables for communication between subroutines, reports, etc. Now in an OOP program, all variables would be local (ideally) and therefore I can use any naming I want i.e. without any prefix. Therefore, a name like delivery_item or delivery_items tells me the difference.
However, when I am inside a subroutine called from a report and I have delivery_items, I do have to navigate and check in the source code whether the developer has intended the variable to be used outside the subroutine also or is it only a local variable so I can change the same safely. In this case a li_delivery_items saves some precious time by telling me it is safe to be used.
Another example can be the indicator of a parameter to a subroutine or a parameter on the selection screen: p_plant or p_purchase_order which invariably helps me to understand that I should never change this variable as it is basically an input from the user.
I know you might be able to give me 100 other reasons why this is wrong. However, at the end of the day when I have taken screenshots of it to explain the issue or the solution to other developers, it helps me avoid the cross check with SAP every single time.
Please note, I am not a fan of li_ekko or li_cekko as these never give me any information other than confusion.
I hope it is clear now. Cheers!
Check out the SAP Press book: "Official ABAP Programming Guidelines". It essentially says that all these prefixes are of no benefit and can actually clutter the code more. Yet I still see them used in lots of SAP code.
I fully agree. I'm always astonished how much energy is put into naming conventions. Ours are very simple: tables and working areas are prefixed and the name after the prefix should be the same so that you can see easily the relation between them.
And for historical reasons object names do have a HR FI CO somewhere in the name cause the packages are very flat and simple. No one will pay money to reorder that just to get rid of the abbreviations in the name, so i just left them there.
Anything else in our development guidelines are dealing with do's and dont's due to security or performance
Hi Rainer,
with packages, I really think it is never to late to start. A package per functional development and potentially sub-packages under that to divide between UI and model. It really makes life easier.
From the support perspective, it is amazing how much easier it makes things to find.
can understand use of similar names to link tables and lines.
data: manager type zemployee_details,
managers type zemployee_details_tab.
loop at managers into manager.
...
π
easy enough to understand isn't it?
Thanks for commenting !
Well its never too late, but you need ressources and someone has to pay for it. In these times its hard to find a sponsor...
And: into is evil π its not allowed in our guidelines
<sigh>
Did the designer of those guidelines ever explain why they thought into was evil? Probably some misplaced belief about performance benefits of pointers versus variables. In which case they probably need to learn about lazy data loading http://en.wikipedia.org/wiki/Copy-on-write and how ABAP doesn't actually load into the variable unless you modify it.
Since you gain no benefit from assigning to a field symbol then your code suddenly become a lot safer place. The idiot coder who manipulates the value with no intention of updating the table doesn't actually update the table and a lot of potential support issues disappear - AND your code doesn't suffer a performance issue.
And yes I have seen this same coding standard and had to actually write some programs to run the same data through the assigning statement and the into statement before the architect in charge of the standards believed me. (but that was one I wasn't going to be convinced out of due to the inherent danger of using pointers when you don't need to.)
Use assigning only if you are intending to modify the values, and then it becomes clear why you are doing it.
But I guess I'm preaching to the choir here π
You should really write a separate rant post about this one π
Of course you are gaining a lot of performance especially when copying wide structures back and forth.And: Field-symbols are no pointers.
If you know that you are facing a rattlesnake ist less dangerous. If you know that you are assigning a field-symbol so simple do not touch the value if you dont want to. Whats that kind of programming changing the varbiables value if the change isnt necessary?`
Use assigning always especially when you have large und wide tables. regardless if you want to change the values inside or not.
And believe me or not: we never had a failure due to changing a field-symbol without wanting to update the table.
What you are describing is bad programming style. Its the misuse of a variable to stere some date elsewhe just because the programmer is to lazy to declare a temporty help variable. This makes code more readable to show the intention.
Hi Rainer, did you get the bit about the copy-on-write thing? There is a very short bit on it in this SAP help doc - http://help.sap.com/saphelp_nw70ehp2/helpdata/en/88/84fb5269d34838a1f119b41dcdbc57/content.htm
search for "Copy-On-Write".
Unless you actually modify the value there is no performance benefit from using a field symbol over a variable. Wide structures or not.
Perhaps the developers you work with are very careful, I've unfortunately come across the other kind.
We'll have to agree to disagree on this one. I think only using field symbols when you are explicitly modifying the table and using variables at all other times not only adds to the safety of the code, but also to the readability.
I'll agree that sometimes it is helpful to show the temporary helper variable to make code more readable. and the silly example below is probably a case in point. However, sometimes the code is just as readable without. Really you've got to start trusting your programmers to realise which is which. Educate them by making them run training/handover sessions and stop trying to force them to be better programmers by enforcing standards that don't make sense.
I'm not agreeing to disagree. Taht a table is modified in a look is common in every language. ABAP is a single point here. So every programmer is aware of changing content in a loop. If someone is misusing a working area for storing intermediate resulöt cause this does not affect the table is in my opinion a bad programmer.
And you arew not going to convince me. I tuned several ABAPs running 20% faster by just changing the ABAP code without having a look at DB indexes. We never had failures like this, but failure because it was unclear if the hedaer line was modified or the table itselft. Therefore tables with header lines are not allowed (with exception like screen or the PA* structures in HR) and as a second step into was banned bringin people to the fact to use field symbols. In the past they always used into even with modifying resulting in bad performance. Again: if you are facing a rattlesnake just walk around.
The other effect is having a development guideline which is small in size without too man exception. Nobody will read this and therefore follow it if you have hundreds of exceptions and more then 100 pages . Clear and simple rules will be more followed and our expereince is good. If yoiu have a loop without modifcation and usinf into you have to change a lot more if it comes to the point that modification is need.
We can discuss the next 5 years about that, you showed your arguments, i showed mine. Working in my company you have to follow my rules, and in your company i have to follow yours.
I just had to check this. I did a performance test using INTO, ASSIGNING and REFERENCE INTO. I tested this on two separate servers.
The results below is in microsecs, looping over an internal table with 100.000 entries (without any code between LOOP-ENDLOOP).
Relatively speaking, ASSIGNING is much faster. But this just means that it is even faster than the INTO option.
System 1:
Using INTO : 41682
Using Field Symbol: 26508
Using Reference : 26670
System 2:
Using INTO : 17111
Using Field Symbol: 6258
Using Reference : 7187
This is the code I used.
TYPES: BEGIN OF ty_st,
f1 TYPE i,
f2 TYPE string,
END OF ty_st,
ty_itab TYPE STANDARD TABLE OF ty_st WITH DEFAULT KEY.
DATA: itab TYPE ty_itab,
wa TYPE ty_st,
dr TYPE REF TO data.
FIELD-SYMBOLS: <wa> TYPE ty_st.
DATA: start_time TYPE i,
end_time TYPE i,
duration_into TYPE string,
duration_fs TYPE string,
duration_dr TYPE string.
DO 100000 TIMES.
wa-f1 = sy-index.
wa-f2 = 'whatever abc 123'.
APPEND wa TO itab.
ENDDO.
GET RUN TIME FIELD start_time.
LOOP AT itab ASSIGNING <wa>.
ENDLOOP.
GET RUN TIME FIELD end_time.
duration_fs = |Using Field Symbol: { end_time - start_time }|.
GET RUN TIME FIELD start_time.
LOOP AT itab INTO wa.
ENDLOOP.
GET RUN TIME FIELD end_time.
duration_into = |Using INTO : { end_time - start_time }|.
GET RUN TIME FIELD start_time.
LOOP AT itab REFERENCE INTO dr.
ENDLOOP.
GET RUN TIME FIELD end_time.
duration_dr = |Using Reference : { end_time - start_time }|.
WRITE: / duration_into, / duration_fs, / duration_dr.
Wow! that is a fair bit different to the values I found! In this case there is a fair point to be made for using field symbols (for processing intensive tasks were 100 of thousands or more records are processed.)
I'll caveat that I work in HR and we rarely have that many table entries.
Would seem that the lazy sharing as advertised in the 7.02 help file isn't working! (it was a 7.02+ system that you were using Ben?)
Thanks for the insight!
Hi Chris,
I tested this on two different was702-based systems. Just now I also tested it on a was731 based ECC system and the results were basically the same:
Using INTO : 28909
Using Field Symbol: 11100
Using Reference : 13585
Ben
Thanks Ben.
One wonders if the routines to ensure that data is being pushed into the right shaped holes is being invoked with the "into" statement which is taking the extra time. I would have thought with lazy sharing and copy-on-write that the check would have been invoked on the type of the structure at compile time rather than in each loop in run-time. Guess I'm wrong!
I apologize for adding to a very old topic, but I thought I would share my results (using larger ranges) for anyone like me browsing in the future. Again, all results are in microseconds (µs).
100
Using INTO: 67
Using Field Symbol: 46
Using Reference: 47
1,000
Using INTO: 650
Using Field Symbol: 307
Using Reference: 346
10,000
Using INTO: 6443
Using Field Symbol: 2909
Using Reference: 3156
100,000
Using INTO: 64883
Using Field Symbol: 28805
Using Reference: 31187
1,000,000
Using INTO: 244488
Using Field Symbol: 109522
Using Reference: 118660
10,000,000:
Using INTO: 2436267
Using Field Symbol: 1094359
Using Reference: 1186491
I did these tests primarily to test the performance in smaller ranges, knowing that some algorithms excel over smaller sets while some excel in larger sets. After these tests, I can conclude that performance appears to always be better not using INTO.
Thanks for sharing these insights, Ben.
I must admit I wasn't aware of this at all, and from gut feeling I would have assumed the opposite.
My question would be:
how significant is the difference in the average program, where the loop isn't empty. Is the performance you gain from the shell usually significant compared to the whole processing time of the loop including its entrails? Of course, whatever the answer, doesn't take away any of the millisecond you save, but if it's 5% rather than 100 in the average program, someone might still prefer INTO for the sake of readability.
Anyway, I'll certainly remember this one.
Then what about sheep?
Plural of a sheep is sheep.
loop at sheep into sheep is not possible. you can't define two variables with the same name.
using a header line is a nono (you said so yourself)
loop at lt_sheep into ls_sheep.... possible.
π
edit: ps: I saw someone on twitter make the argument that the singular for sheep should be shoop if it followed the rules of english spelling. π
As into is a nono π better use
loop at sheep assigning <sheep>.
Loop at flock into sheep.
wool = sheep->shear( ).
stockpile->add( wool).
endloop.
although I'd generally do without the intermediate variable and
stockpile->add( sheep->shear( ). π
This is getting silly π
I like it π
oh and I realise now I'd probably get into trouble for not running the pretty-printer through that last one... and I think I forgot a closing bracket π
Darnit, I really thought I had countered you with the Sheep.
Funny thing is that I do understand your rant. I never actually use LV_ outside of ABAP.
But than again, I'm one of those people in charge of writing code guidelines. (although I did throw away the old naming conventions and simplified them into Hungarian) (you would get a heart-attack if you saw what was previously used)
and yes, loop at assigning is in the code guidelines as well, but not obligatory. Loop into is also still allowed. (you'd be surprised how very few developers understand safe and proper use of field-symbols. When was the last time you saw someone use the unassign statement? or "is assigned"? )
I don't get your sheep sample.... If flock was renamed lt_flock and sheep ls_sheep it would magically become clear to me! π
I've only got two sheep - so it's hardly a flock...
LOOP AT sheeps...
we're writing ABAP here, not English literature.
Lol'ing ... π
Personally I would prefer:
loop at mob into sheep.
but if you like your collective sheep as flocks then that's fine too.
On a slightly more serious note to your OP. I agree there is no value in the lv malarky but I have been using it due to that is what is generated in a lot of CRM code.
If something exists in the scope of the class then i will occasionally use a me-> to make that explicit if I think it needs it but in general you are right the lv_ adds nothing.
There are _rules_ to English spelling (other than to press the spell check button often?)
Ralph Waldo Emerson said 'A foolish consistency is the hobgoblin of small minds' - I have often thought of this quote and indeed, I have embedded it into the mandatory comments in some programs.
I have no objections to guidelines, and I have no objections to adhering to some gentle naming conventions. But as someone said earlier in this thread 'ABAP programmers are stubborn and creative' and I would also like to add, smart (for the most part). Give us the freedom to name out variables the way we like? Don't include mandatory documentation templates that are essentially meaningless and only serve to clog up valuable screen editor real estate? Let us determine that white space is actually a good way of calling out important functionality?
Chris, I think you've opened up a can of worms here, and I can wait to continue reading the comments.
Good job!
Ha what is life without some worms to wriggle with. 😏
And quality of comments pretty high too!
Wonder if most agree with the whole package thing as objections seem mainly to be about Hungarian notation.
I too will watch comments with interest.
The only readability benefit is that when developers are used to a variable defined in a certain way like it_ or i_ they instantly recognize it in this case as an internal table.
ABAP naming conventions - MEH! π
Blasé know it alls who can get away with whatever they want - bah π
Use of packages is definitely very useful in both trying to look at standard SAP objects and ( if properly done ) with custom developments.
However, about variable names - Compiler/Interpreter doesn't care either way. Like any norm, it's there to reduce the cost of semantics. Some naming conventions look useful in ABAP in so far they convey the meaning.
Looking at variable names in ABAP vs Java/ObjectiveC/Javascript, I can see at least the following differences:
- Variable name length : ABAP doesn't allow you to use really long variable names ( more than 30 chars ) whereas you can make them really long in other three and they're encouraged ( esp. in Objective C ) .
- ABAP variable names are case insensitive => You can't use camel case and use underscores to make it more legible.
Currently, we use semantics for both type system as well as variable names. Looking at the managers example by Chris, I just see it as a different convention with the semantic no longer being in variable name and transferred back to checking type system. I'm not sure if I want to lose that meaning in the variable name, especially if I get auto-complete in eclipse.
May be the world will be better with only one convention for all languages .May be not π .
Hi Chris
Nice blog post. I totally agree with the premise of your argument that "semantics" in a variable name is more important than "type". I really don't like severe and unnecessary conventions either but I'm still a fan of some minor conventions. For example, I quite like the lv_, ls_, lt_, lo_ etc convention for a few reasons:
1. It makes the variables stand out from the keywords. Yep, I know that editor features like "keyword uppercase" and font colours/styles can help too so this argument is a little weak but there are times when some of these features aren't available (like when comparing code versions)
2. It makes the variable "type" instantly recognisable without having to read the context or jump to the definition. I think this makes the code quicker to read. But then again, maybe that's just because that's they way I'm used to seeing it and its a personal comfort thing rather than actually being more efficient for every programmer?! Dunno...
3. It allows me to have multiple variables with the same "semantics" but different "type" within the same scope. Playing devil's advocate here... in your Manager example above, how would you handle the situation if you needed variables for both a structure of manager data and a reference to a manager object?
I've purposely double-quoted my use of the words "semantics" and "type" in this comment as I can't help but wonder if the v/s/t/o part of the common naming convention is actually providing semantic information more than type information. For example, "ls_manager" is a local variable that refers to a manager data structure, "lo_manager" is a variable that refers to a manager object. In the context of a program, is the v/s/t/o part of the variable providing semantic information?
I don't have any arguments to support the used of l/g to denote the local/global scope of the variable. I think I use these "just because"... π
Anyway, thanks for challenging my thoughts on this topic. I hope to be challenged some more by your response. π
Cheers
Glen
Hello Glen,
You've pretty much said what I wanted to but couldn't find the time to. I agree that using those prefixes allows you to immediately know the variable without having to double-click and navigate to the definition. On the one hand, you save time by not adding those prefixes but on the other you spend time double-clicking and navigating to the definition and coming back.
Hello Kumar,
You are right about this if you are referring to procedural code with lots of global data that is separated from the actual logic. In these situations using prefixes could maybe add a little value. Although, using TS_ for sorted internal tables becomes a problem when changing the table type to hashed or when defining a few secondary keys for the internal table. Do we have to change every reference to the name everywhere?
However, if you limit the use of global data to the minimum that you need to make things work (technical requirements of ABAP) and use local data and formal parameters of procedures, you don't need to double click: the specified variable is only a few lines separated from you code. And for local variables, you could even choose to define variables just before you are using them.
Especially when using proper OO design techniques and adhering to principles like SOLID the size of your classes and methods will be limited and you don't need to use prefixes or suffixes anymore. Using an L_ prefix for a local variable in a method that is only 20-50 lines of code has no added value anymore. Defining an attribute called 'ORDERED_MATERIAL', referring to a material object, or a local variable 'SALESORDERS' referring to an array of Sales Order objects is a very workable and readable solution.
Cheers
Ben
What Ben just wrote. Totally on it.
Ben, awesome comment! And exactly what I meant but was too ranty to explain! π
Thank you!
Chris,
Thank you for starting this discussion by your rant. Was not too ranty for me. Maybe you have some more rants within you to start other important discussions. I'll be looking forward to them.
Ben
Hi Ben
I'd be interested in your opinion on using v/s/t/o to differentiate, for example, a data structure from its semantically-equivalent object reference... This was the main concern of my comment above, not the global vs.local.
Glen
Hi Glen,
If a method (or function or routine) only has a limited amount of code lines, you are not going to need a lot of variables (and even less so if you can use method chaining π ). The few left can have any name, if the name describes what it is. For me, o_order or order or order_ref are all ok.
My methods typically only use importing and returning types. Maybe if I had to use a changing or exporting type, adding I_, C_, E_ would make sense.
Cheers,
Ben
Good article, couldn't agree more. It's funny because the use of Hungarian notation with statically typed languages such as ABAP, is based on a complete misunderstanding of the notation's intention.
I've completely stopped using the Hungarian notation years ago (I was taught to use it when I first started writing ABAP, as most of us probably were), and everywhere I see this convention I explain why it's useless and even reduces code quality (due to the fact it get out of date fast which means lots of renaming which is hardly ever done).
I also organize all my code into different packages. It makes everything a lot more maintainable when you group your code (domain, ui, models, services, etc.).
I too am making the journey from being anal about names to tring to make things look as much like natural English language as I can, the so called "literate programming" style, so the casual reader can have a better idea of what is going on.
I would however note that I am now making a distinction between OO programming, where I try to name variables like natural language, and procedural programming.
There is still a hell of a lot of procedural programming around, and there will be for a long time. This very day I came across something where there was a global variable called OK_CODE, and then assorted FORM routines had USING parameters also called OK_CODE, and sometimes you had local variables also called OK_CODE and it was almost impossible to tell what was going on.
In a really complicated messy procedural progam which you are not allowed tro totally rewrite as it is so business critcial, you find yourself dealing with a bunch of variables all of different scope, parameters, local variables and global variables, and you have no idea how much downstream effect changing one variable might have if you can't be sure of it's scope.
That's a bit easier to handle in OO world!
The other thing of course is that if there are one million ABAP developers who are in favour of naming standards, you get one million different naming standards.......
Very well said Chris Paine.
But following such conventions always help. By that you need not to 'Double Click" each and every time you have to see the scope of any variable.
and also at times you have to see the code snippet and find the problem with actually getting to the SAP system. These convention do help a lot in understanding.
You always have to do that cause you cant insure that all these prefixes and suffixe are correct. If it is an exporting or importing parameter can be a quick check, but you dont wanna say that the tyoe should be encapsulted in the name???
Just as an aside, you can set the code inspector to check if variables that start with L_ are really local, or that start with G_ are really global.
As has been said, the worst thing in the world is to have a local variables that starts with G_, or a global variable that starts with L_.
Again I stress this sort of thing is far more important in procedural programming.
As others have said, a few judicious prefixes can make it more obvious what's going on. While double clicking on th_appraisals will show to me that it is a hashed table, if it's named so, then I save time by not having to double click. I'm all for saving time when developing, but far more important than that is saving time when fixing and enhancing, since the major cost of any development is not in its creation, but in the maintenance. Whether the "h" for hashed is necessary is more debatable. I'm wavering towards "probably not". As an Objects developer, I don't need to use l_ for variables within methods - they're all local-. If I prefix parameters with i, e and x (or something) all is clear. Attributes are prefixed with me->.
So, I kind of agree - but I wouldn't do away with prefixes entirely. Even in Java, I make it clear what's a parameter of a method, what is local, what is an instance attribute (this) and what is static (classname).
My personal "favourite" is field-symbols such as <fs_name>. It's surround with angle brackets. I know it's a field symbol, it can't be anything else!
If SCI is so good at spotting violations to variable naming conventions, why doesn't it do something about it. Perhaps it should be developed to not just highlight "errors", but fix them? π
The <FS_*> is one of the most bizarre ABAP naming convention. Totally agree with you!
I'm a big fan of standards, but too have evolved into simply "guidelines", which is what we have in our organization. Whatever works and makes sense is fine. As long as there is no stuff like 'itab1' or 'p_1' or 'temp' - pretty much anything goes. I do use 'lv' or 'itab' prefixes mostly out of habit, but wouldn't force it as a standard on anyone else.
Good blog, Chris - thank you!
I hereby expose myself as somebody who loves these 'ominous' code naming conventions and I'm direly thankful SAP tries to keep things standarized here. Of course this arises from my experiences so far in which I've very often seen "itab" being a work area or a flat variable "wa" being a deep table etc. with a global overhead flying above the entire desaster both in standard code and in custom code.
I understand these conventions make you mad since you know the drill and the things the conventions describe should be natural and self-explanatory. But for quite some people they are not and this makes me bite into my keyboard. Often. So these naming conventions keep codeing-wise organisational desasters in check (in my humble opinion and as per my so far experience).
Cheers, Lukas
I guess it's like speed limits. A minority of drivers know the safe speed to drive at in any given condition, but the majority haven't a clue, so need limits to keep everyone else safe. Maybe one day we could reach a state where if you need to have naming conventions to keep you in line, you're not allowed near a computer. 😏
Several things:in regard to both comments - from Lukas and Matthew -
- I am not 100% convinced standard SAP code does in fact try to keep things standardised in regard to how they name their variables. They often call things LV_SOMETHING, and often they call things SOMETHING and often something else again All this in recently written standard SAP code.
- I also see - in custom programs - variables being named "L" for global " and "ITAB" for a structure etc. Horrible, so the argument swings towards just calling something what it is domain wise, false information is worse than no information.
- In some legacy programs I have had to maintain you have the same parameter three times with the same name, one is a global variable, one local, one a parameter. You can say get rid of procedural programming, but it will be here for a while yet. Is putting the scope in the name really that evil here if you can't change the entire design?
- some articlesI read suggest that the practise of putting the "type" of a variable in it's name - so called "Hungarian Porgramming" was a horrible accident, and never intended by the Microsoft guy who came up with the concept, he wanted to have a semantic prefix not a data type prefix, but he used the word "type" in his academic article, and the rest is history.
This is all just random thoughts, I am not really trying to make a point one way or the other.
SAP code is great. So many standards to choose from!
Yup, standards are there to provide some limits to the flexibility everybody wants.
And when rules are implemented to tame those wild Developers, they will find ways to break free again...
So, yes, Code Inspector will give prefixes, and lazy efficient (?) programmers will circumvent these ANNOYING and USELESS restrictions by naming tables TA1, TA2 etc. Very useful.
Others will be more descriptive and name them TA_THIS_TABLE_IS_TO_STORE_THE_DATA and ST_THIS_STRUCTURE_IS_USED_FOR_THE_TABLE_TO_STORE_THE_DATA. Or do I exceed table length?
Best way would be to simply hit the programmer, if naming conventions do not match the client's standards.
Yes, start your program with Y. MY_ABAP_PROGRAM is also valid. If I have a name space, I just use that prefix.
Great post, great comments. Suprised that WebDynpro didn't came up as a subject, seems no logic there for using a local/global prefix.
Personally, I always use prefixes ( and prefer it) but ... except for flags such as: is_dirty, is_something, this way is it more readable in the code. I also try to use _ as prefix for private variables.
( field symbols i use same naming convention as variables but with < >, indeed <fs_*> doesn't have any value ).
I just came across this article - http://theweek.com/article/index/243963/the-language-isaac-newton-invented- and thought it might find relevance in this thread π . Newton would have liked naming conventions π .
So, in a way, Isaac Newton invented Hungarian notation!
In a way.
I absolutely share your frustration about this kind of formalities taking over as a pseudo quality measure.
You probably can argue about what's easier to read and it may be different for different people, so I'd not necessarily attack any naming guidelines, but they should be succinct, easy, memorable within 5 min and a guideline rather than a religion. Neither should setting them up consume a lot of time (i.e. more than 2 hours or so).
Someone, who performs quality checks on the basis of naming conventions should, given Capital Punishment isn't an option any more in Britain (or Oz), be fired immediately.
However, there are some objects where naming conventions make sense. Such as everything you might have to use explicitly in an authorisation object.E.g.: It is easy to assign rights for all transactions ZHR* or ZHR_nn* with nn being the MOLGA in case of country specific transactions.
So, once we are not talking names within programs, but object names, a closer look might be sensible.
Very enjoyable and sensible read. Thanks for that!
Just a short comment:
The main (and maybe only) purpose of naming conventions is readability.
Although I appreciate the double-click option (and I do!), it doesn't help you understand the code by just reading it.
P.S.
Naming conventions guidelines should enfore not only type prefix, but also informative description of variable.
It's worth reiterating that the usage of the variable generally shows its type. You can't append to a field, you can't subtract from a table, calling a method of a string won't work.
why you'd need to double click to understand variable type I just don't get.
Also as explained above, very often the name goes wrong.
You just have to look at the interface for the FPM list GUIBB for an example. In method IF_FPM_GUIBB_LIST~GET_DATA the importing parameter is IV_EVENTID but it actually refers to an instance of the class CL_FPM_EVENT.
one needs instead to read IV_EVENTID->MV_EVENT_ID to get the id. If I was just looking at the stupid prefix, i'd be in headspin, but if I notice that it a object reference due to the "->" I can figure it out pretty quickly.
If we didn't have the naming convention, we'd never have been confused.
Good point. How many times have I seen a L_VAR that's global! Bad coding is just bad coding. No amount of prefixes will fix that. I shall forthwith, client standards permitting, drop prefixes altogether...
I still run into table names like T1, T2 and T3. That is following a naming convention and oh, so very useful to know that it IS a TABLE.
I saw constant c_seven yesterday.... type n, value '7'. π
Amazing... That really must have added some value.
ic_dead_people I could understand. Maybe c_seven is also a movie reference?
I did create an FPM event the other day "DO_OR_DO_NOT_THERE_IS_NO_TRY" which was kinda undermined by being tested for inside a try-catch block.
I'm auditing a lot of abap code right now, and run into a constant:
CO_D TYPE C VALUE 'D'.
This way, I don't have to be confused when I read in the code:
IF PA_TO <> CO_D.
Self explanatory or what!?
IF_MSS_CAT_APPR_BL_CONSTANTS
nuff said.
Oh grief... *shudder*
Stunned - why didn't they name it C_7? π
Hi Chris,
I agree that IV_EVENTID is a good example of bad usage.
However, the fact that some people (mainly in SAP) misuse naming conventions doesn't mean the whole concept is wrong.
I may also accept that variable type (simple variable, structure, table) prefix is less crucial(although it can still help in readability), but variable scope (global, local, static, member) or parameter type (import, export, changing) cannot be understood without checking the variable definition.
Anyway, as I've said before, naming convention is more than just prefixes. Giving a meaningful name is more important.
As Matthew said, "Bad coding is just bad coding".
However, using correct naming conventions may make good coding more robust and readable.
Hi Edwin, I think what you're speaking of is coding style. Not to be confused with code naming conventions which is the hot topic here. Ie. aligning your type declarations. Largely this is taken care of for us by pretty-printer. Otherwise we'd be arguing about how many spaces (or tabs) to indent as well. π
Yes, probably a bad example. The point I tried to make was that developers work in differnt ways. In coding style, as well as in naming conventions. Basically, in everything they do.
Maintaining each others code becomes a little easier or sometimes a lot easier, when there is a common look and feel. Naming conventions can help in achieving a certain level of familiarity within the development community.
It is difficult to describe this properly, in words. But providing a set of rules can help in providing limits to the "Don't worry I know what I am doing"-cowboy mentality of programmers. The "As long as It works" methodology.
Even when people write the same language it does not mean that the meaning of the words is clear. "Please do the needful" makes perfect sense to a lot of people, to the others it feels 'wrong'.
I've just started writing a few programs without the usual prefixes. Strangely liberating...
Expecting flames for fhis...
I think its quite disheartening to see all the comments from people that need prefixes throughout their code to be able to understand it. Either you need to learn your trade better by reading great books such as clean code by Robert Martin or the code you're looking at is rubbish in the first place (if you're looking at SAP code its highly likely to be rubbish. Particularly old code or anything in the HR module ;-). ).
Also - check out the advice from the official ABAP guidelines book available from sap press where some research has been done into this subject with the result being that prefixes everywhere add no value and in fact clutter the code.
[embed width="425" height="350"]https://www.youtube.com/embed/r6QmMZg1ubE[/embed]
You asked for it... π Will be interesting to see what responses you get!
There will be users of that fire saying that is doesn't work.
Thanks Chris, the video instantly made me feel warm on a cold afternoon. π
Well i can see that a lot of people always combines naming conventions with prefixed variables. Prefixes are only part of that. i am allowing prefixes if someone wants to have them in "his" reports, except when changes of the variables will disrupt the context. A table prefix saying that this is a sorted table is in my eyes nonsense, cause you cant change the type to hash anymore, you have to go through the whole object and change the name.
Some with these constants which cant be changed. a C_119 containing 1.19 for tax calculations is worthless and it doesnt increase readability. It should be c_tax_for_this_and_that, and now you need to change only the constant declaration. I knowm this is a bad example cause this should be somewhere in a table, but you can get the point.
It seems to be a small world, isn't it? π
The revolution begins!
Everybody's doin' a brand new code now
Come on, baby, do the revo-lution
I know you'll get to like it if you give it a chance, now
Come on, baby, do the revo-lution
(Sorry, just kidding)
Honestly, I did not read everything in this excellent blog, nor did I read all of the comments.
My personal conclusion: Hungarian notation does not hurt as much as said above.
My biggest problem is bad naming (although 90% of us know what PO means, we still have enough space to call it purchase_order - the typing (or copying or autocompleting) a couple of characters never take more than, say 5 % of our coding time.
I'd wish more developers follow the rule "one step - one module" (whichs ends up in "no more scrolling" within one Form/method/function/program.
For me, it is helpful to have names like lt_ekko, I prefer lt_ekko_cross_company (still 8 characters less than limit!) because I know it's a table, I know which fields I can expect here, I know the developer avoided global fields. I'd be happier about an RT_ prefix used in a functional method, but...
The reality shows: Most companies do not encourage developers to change their way of doing, so we have to encourage ourselves. We know that most ABAP developers still merely can read oo code and never would create it.
Companies built the R/3 system 15 or 20 years ago just think "never change a running system" and invest heavily into maintenance of undocumented spaghetti code π
For me the I, C, E and R parameter prefixes are as useful or useless gt or lt.
Most important is the naming (we have 30 characters!!) and modularization of reports, classes, methods, functions and (no use) forms. And it is true:if the naming is proper and code lines per module does not exceed, say 20, virtually no additional documentation it needed. Anyway, I love to paste parts of the functional specification as comment into the code - to let maintenance people know the sometimes really weird requirements π
stay tuned, Clemens
I may be repeating myself here, but maybe this is not the end of the world.
My understanding is that the whole idea of "Hungarian Notation" started as a horrible joke gone wrong. A guy at Microsoft posted an article called "Hungarian Notation" where in the introduction he explained about naming things like GT_THING and then spent the rest of the article knocking the idea into the ground.
But people only ever read the introduction and so presumed he was in favour of such things. So much so that it became official Microsoft policy to name things using Hungarian Notation.
I started off using the exact same notation e.g. LT_THIS or RT_THAT, but then one day I woke up and now my main goal in life is to have code that reads like English so you do not have to have comments.
IF NUMBER_OF_MONKEYS GE ( INFINITY) THEN PRODUCE_SHAKESPEARE
as opposed to
IF ld_monkey GE (id_monkey_number) THEN PERFORM play_writing.
There was an academic called Donald Knuth who came up with an idea called "literate programming". It could be said he went a bit too far, but the idea of programs that reads like a novel as opposed to X == Y (F)^45 surely has some merit. Often programmers realise their code is meaningless and add comments to try and explain what they are up to.
If you reduce the comments then more fits onto the screen, and since developers spend much more time looking at code than writing code, the more clues/hints you can give your fellow developers - or indeed yourself - the better,
Cheersy Cheers
Paul
I'm feeling pretty depressed. Just got access to a new SAP instance... and to have the roles assigned I've got to read the standards documents including naming conventions. Not only are the documents clearly out of date, they also insist on prefixes.
Now, I can accept moving from client to client, having to conform to their standards - no matter how dumb they might be. But in this instance, the naming conventions are not only inconsistent among themselves, but don't match the conventions required for systems that were first implement over ten years!
So now I've got to "learn" different naming conventions for different systems within the same client.
I've escalated it to one of the managers and plan on having a good rant about it to him, tomorrow.
I've seen many developers never inform about that for (10) years. In fact, they never told the responsible manager that they don't respect the standards anymore. I have talked to the developers, and they don't mind. Even the managers don't mind in fact. They prefer to continue telling people they have standards and so on... Big hyprocritism. So, really don't insist! π
On these issues I tend to beg forgiveness rather than ask permission. π
That's always been my philosophy. On one of the other system streams for the same client, I used i_ e_ and x_ for method parameter names, when (ooo what a rebel), the standards say imp_ exp_ and cha_. But when it came to code review, these were considered minor issues, and so didn't need to be changed.
I'm concerned this new mob may not be so pragmatic.
In the same "standards":
π‘
...and rest... π
Depending on your database (Oracle/MS) using FOR ALL ENTRIES all the time is NOT recommended. Don't get me wrong, it is a useful clause to use, but it also has its downfalls as well. Their are a host of database parameters that dictate how this clause will work so it can be tweaked to push more data through, but, if you look at an SQL trace when you use that SQL clause and you'll see exactly what I mean. It's strangely not the most efficient SQL clause when huge volumes are involved. A good join statement should always be better, especially if your WHERE clause more or less produces the same result set of what would have been in the internal table used by the FOR ALL ENTRIES IN clause.
In the REAL world having a standard that says never DELETE code just will not work, especially if you have code more than 5 years old. I have worked on code whereby it's almost impossible to work on a large ABAP program just because of the sheer amount of code changes and redundant code. So cleaning this up, after a number of years is well worth it. I recently updated a program which was 11 years old and had about 45 changes documented in the header. It was almost impossible to determine the flow of the program until it was cleaned up by removing redundant code. π
FAE is particularly problematic with HANA. Though where you have to use it, there are some techniques to make it more efficent. Note 1662726 has details.
Mathew, Interesting to know that. I'm currently cross-training to HANA, with the idea in specialising in HANA performance/optimisation, so would be interested in hearing of any other HANA related performance issues. Do not want to change focus of this thread though, so back to coding standards...
One thing that I have found to be lacking in a good few large companies, and that's the quality of the peer checking process for coding. If the developer knows that the peer checker (often a colleague) will reject his code if it does not conform to standards (naming and coding wise) then they are more than likely to follow the standards put in place, especially when the peer checking has to sign to say that they have performed the agreed checks. π
Where I find peer checks lacking is in the results section though. Any peer check against code should not only check the naming standards but also the code itself to ensure it's efficient, and that it achieves the goal set out. So a print/screen dump showing the results, being a report of output to table etc., should be included with the code when peer checking, plus, more importantly sometimes, is an ST05 trace/explain for every SQL statement in your code, to show that it is efficient. This trace should be shown in production environment, by grabbing the SQL (native) and then pasting it in ST05 and asking for an explantation of the SQL. If this is done then over a period of time the developers get better, as they learn from mistakes, especially when rejected via a peer check, and the code (naming) gets better. Everyone benefits, which is the aim of a peer checking process.
Then trow away their standards, and replace them with a link to http://help.sap.com/abapdocu_740/en/?file=abenabap_pgl.htm
I just had to define a Code Inspector variant for specifically checking the "naming conventions". In the email i sent to my fellow developers with the details of the CI variant, i wrote -
Well, we had a little chat, and the standards will be revised. π
Squeaky wheel... π Glad to hear. Our guidelines are rather laid back and only "suggest" some prefixes. We don't force anyone to use them. As long as I don't see stuff like "itab1 / itab2" I'm a happy camper. It's amazing to hear how many development leads seems to be on some kind of power trip with their standards...
Funny story. After reading all this moaning and groaning about the prefixes I tried to get rid of them in one program. It seemed pretty obvious that we should stop using "T_" in types (because what else could it be?). So I called some type "orders" and was quite proud of myself at first. But then when using this type I got a syntax error saying some field did not exist. After cleaning my glasses and checking two times that the field is indeed declared I started to poke around and discovered that there is also a dictionary structure called "orders". Gee, thanks guys. π
Back in 1999 in Tel Aviv, the programmer who got me started on the ABAP path told me how surprised he was that in ABAP you could name your variables the same as dictionary objects, or even keywords.
In the previous language he had used it gave you an error if you tried that. The ability to "overshadow" variables and the like causes all sorts of grief in procedural programs where you can have OK_CODE as a global variable, a parameter and a local variable all at once.
I suppose it could have been worse - you could have a type called orders in our program and everything was fine, and then in a support pack SAP would create a new dictionary structure called "orders".......
A typical generic-purpose language doesn't contain 800 keywords. I like the fact that I can declare a variable called "message". π
Variable (and even method) shadowing also exists e.g. in C++.
Does that mean we have to use something like z_orders_ty? Or simply always declare types in the data dictionary.
We used to use t_.... for types. Interestingly, I checked for dictionary structures and didn't find any that start with T_. π
Was actually a bit surprised that dictionary definition "trumped" local one, thought it'd be the other way around... Leave and learn.
itab1 and itab2? Not bad... That at least sounds like a word. I've had the pleasure of debugging programs with the short versions. T1, T2, T3... O, joy. I had to rename everthing to make it understandable before I could look for the error.
You are right. That's why I name my three local variables WRITE, LOOP and ENDIF. π