ABAP naming standards, anno 2013.
Just recently, I was asked to produce a document on abap naming standards. It felt like stepping back in time.
Back in the eighties, SAP had its large-scale boom into the large enterprises and SAP development was predominantly done in the ABAP language. Object oriented ABAP wasn’t around yet and large number of suitable and unsuitable people were trained very quickly in ABAP academies to go and produce lots of bespoke ABAP code to complement the standard SAP solution. The core SAP modules weren’t as feature-rich as they are today and a lot of add-ons that you can now get off the shelf didn’t exist. So we did what we had to do… we produced lots of procedural code scattered around the SAP system. The problem with procedural coding is that as soon as you start to break the code down into reusable chunks, you end up having to carry loads of parameters around between the different coding blocks (you don’t really have to, but that’s what happened). And I believe this is where the idea of ‘naming standards’ was used and abused. Reading up on ABAP naming standards on the web, it looks like some coders were satisfied if importing parameters started with i_ and internal tables started with it_… With hindsight, this was perhaps a necessity at the time to see the wood for the trees, but today we are looking at a very different picture and a very different set of options and opportunities. I think it’s fair to say that those old style-naming standards did nothing for the quality or maintainability of the code. People also confuse the naming conventions enforced by SAP with coding standards. My question is this: are naming standards of any value in today’s world? Do they help to deliver quality code?
What is good ABAP code in 2013?
Firstly, ABAP development is only a piece (small?) of the SAP development landscape. It is still core to SAP but we all know SAP GUI (the traditional consumer of abap code and screens) has big limitations and will never look as snazzy as a modern web page. SAP have gone out and bought a plethora of software solutions and integrated them (sometimes WIP) with the core modules. Those software solutions inevitably use a different development platform.
Secondly, the core SAP modules are incredibly rich and well integrated and there are loads of add-ons that can be downloaded and activated for specific industries. The need to write lots of bespoke abap code has diminished dramatically. In fact, many companies have tried to go back to out-of-the-box SAP to reduce the maintenance overhead of bespoke code. Probably the best ABAP code, is the code that was not written! (Because the ABAPer made the effort to go and look for a standard out-of-the-box solution).
ABAP development can (should?) be done in OO now. In fact, all the newer technologies that have been introduced like web services and BADIs and the entire enhancement framework use it. It’s hard for a modern ABAPer to do a good job without ABAP objects. OO allows for a lot more structure and reusability in the code. Having said that, it also allows for over engineering. Loads of objects (ABAP classes) are simply part of frameworks rather then representing business concepts and entities. We’re only a couple of decades into ABAP OO and you pretty much need a PhD to understand the frameworks and to work out what objects to use when and how. Sometimes I feel we haven’t made all that much progress towards good code.
I believe that good abap code is written in reusable classes using business language, naming objects for what they really stand for, leaving all “clutter” prefixes behind so the code says what it does. So no more customer master data called “it_tab” but rather “list_of_customers”.
Look at this small example: this code snippet works out what the next batch number is: for A000005, the next batch number is A000006; for B999999, the next batch number is C000001. You get the idea.
This code is readable with little effort. Note that the person who wrote this, investigated first if standard SAP number range functionality couldn’t do this already… so as to avoid writing this code altogether!
Good abap code anno 2013 is covered by unit tests. The two examples above (A000005 and B999999) are written as abap unit tests. These unit tests can run in automated fashion to prove that the code does what it’s expected to do. At the same time, they document the behaviour for the next coder.
In summary, I believe good ABAP code is code for which SAP offers no alternative, that is easy to maintain because it is readable, guaranteed to work (as proven by the automated unit tests), is not over engineered and mimics business concepts and process components and is therefor more likely to be reused.