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.

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 year 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>