SAP Architect Matthew Montano continues his series on the Vortex Consulting blog:

In my experience, there are generally two circumstances where we end up reading SAP ABAP source code. The first–we need to improve custom functionality and so have to understand how it was built. The second is when the red siren light is flashing–and we’re on an open-ended, 24-hr. emergency conference call about missing invoices, reviewing code that was copy-and-pasted from an acquisition 15 years ago and trying to understand what broke.

In neither circumstance should ABAP source code read like a new installment of Dan Brown’s The Da Vinci Code.

So why do developers author code that might only make sense to themselves?

SAP ABAP is an optimized language. Consultant hours are expensive. Given that bytes are essentially free and obnoxiously clean code with extensive comments makes no impact on system performance, there is no reason that any code can’t also make some friends.

The vast majority of the ABAP source code that is authored is solving a business problem (that theoretically hasn’t been addressed by SAP already, which I have plenty of thoughts on…but that’s a different post). So if the code is trying to solve a problem, there’s a good possibility that the underlying business requirement (or those nasty assumptions) has changed, so chances are very good that a business user (aka a functional consultant) will need to read it at one point.

Your average SAP consultant probably has some development experience from when they learned BASIC on their Apple II or Commodore 64 in the 1980s. The younger ones might have learned Borland Turbo Pascal on an MS-DOS clone in the mid-90s. Most of us can stumble through nothing more than a complex Excel formula.

But too much ABAP source code I see is missing any narration of what the requirement is and how that requirement is being addressed, especially when using complex ABAP commands.

Whatever your organization’s approach to solution documentation and change management may look like, there shouldn’t be a single line of ABAP code that is written (or changed) without a clear reference to an Object ID, requirement, or change number. I’m a functional consultant–not a crime scene forensic detective. I’m not even adverse to seeing wholesale chunks of the functional specification straight in the ABAP source code.

Does the code use one of those fancy new ABAP constructors such as “dereferencing generic references”? That’s all and well–but could you throw old dudes like me a bone as to what the code is intended to do? (I guarantee any other senior level consultants involved will appreciate the gesture.)

(Using an “if” or “case” statement? Why not tell us what you are IFing or CASEing?)

And I’ll go ahead and offer one more tip while we’re here. This one starts with a question: What is with variable names turning into a game of “trick the parents” by using the fewest number of letters possible? ABAP variable names can be 30 characters long. Go ahead and use a few so everyone involved knows what purpose the variable serves.

Customized ABAP source code is almost assuredly the result of a long and often expensive process of requirements and specification reviews and approvals. That code will be subject to testing and probably changed several times by other teams. Given its placement within SAP, it’s doing something important–if not critical–for the business, and it will likely get changed by developers you’ll never meet. ABAP source code should reflect this very important role in SAP solutions and not be treated like an unfortunate afterthought.

If you need help upgrading your ABAP development standards, consider reaching out to Vortex Consulting. Our consultants have decades of experience developing and implementing SAP solutions that get the job done today and are well aligned for your organization’s future growth and evolution. Email us here or call us directly at 1.888.627.3640.

About the Author: Matthew Montano is a Vortex Consulting SAP architect with more than 25 years of experience in Electronic Data Interchange, Supply Chain Integration, and Third-Party Logistics. His passion for good documentation and streamlined work process has yielded measurable results for clients in the consumer packaged goods, life sciences, manufacturing, and transportation industries across both the United States and Canada. Check out his previous posts here: Why Years of SAP ERP Experience Makes Me Question if You Really Need That Custom Code  /  Time Zones in SAP: Let’s Dig In