Part 2 of the “Writing robust, understandable, maintainable, state-of-the-art ABAP programs” very much continues along the groundwork that was laid in part 1 of the free SAP Professionals Journal guide.

One problem I’ve found in the past when working on client sites is that – for various reasons – create/change access to the ABAP Data Dictionary is not always granted to external developers. This obviously poses a problem when trying to implement some of the guide’s suggestions. Part 2 is very helpful in terms of data declaration syntax, internal tables and global/local declarations.

SDN has posted all 3 parts of the “Insider’s guide to writing robust, understandable, maintainable, state-of-the-art ABAP programs”. Here are my comments on reading part 1 of 3.

Quite early on Blumenthal and Keller make it clear that the OO model is the favoured one. This doesn’t come as a surprise as both of them have been instrumental in developing the ABAP language to where it is today. Whilst it is undisputed where the benefits of object-oriented programming models lie, my thoughts after reading about the first 2-3 pages are that this mostly is not a guide for people “out there” in the field. For example, in this day and age where shareholder value seems to be paramount it is hard to believe that a client would welcome it if an ABAPer would re-write any of his/her “outdated” ABAPs without business case. Having said that, there is always the possibility of going over “outdated” parts of code whilst doing other fixes or enhancements.

As far as writing new ABAPs in OO is concerned, I am still not sure that ABAP OO has been adopted widely enough to switch over entirely. I agree that a cutover has to be made at some point, but in my own experience I can not see the whole developer community ready for it just yet.
There are some helpful recommendations, the most important ones in my view are:

• do not re-use INCLUDEs in other programs, but only to structure one ABAP
• use modern ABAP features (ALV, for example rather than classic list)
• in GUI programming, keep presentation and application logic separate
• use Pretty Print as often as possible

A review of parts 2 and 3 will follow soon!