Rant over. Let’s get to work

After my initial rant it’s time to start thinking constructively. I realize I’ve introduced a couple of topics at a very high level and I now need to come up with practical answers. I’ve spoken about code quality and that perhaps wages should be tied to that. I’ve spoken about the need to rate code quality. I have also spoken about standards and rules and providing feedback to the programmers which can help them become more proficient in writing readable and reusable code.

In my previous blog I talked about OO (object-oriented) coding as I believe it is the only way to elegantly structure business logic in small readable and reusable building blocks. I’ll introduce the 5 major elements that I believe lie at the foundation of readable reusable code.

1. I’ll start with the big one: code blocks must be single purpose and hence short. I believe a good guideline is 20 lines (each containing max one ABAP statement) maximum. To many programmers this may seem crazy small but I have very rarely needed more than that especially now that the ABAP language foresees so many powerful statements. Code blocks are: methods, function modules, forms, events in reports and macros (to be avoided completely).

2. Then there is the issue with global variables or variables in general. I often see long lists of variable declarations. They should be a thing of the past. Information should be kept in objects and in reusable data structures (I.e. not declared locally, but rather in the dictionary). In a class the only attributes should be the key identifiers of that instance. For example for a material class (remember a class represents a thing) the only attribute should be the material number as that is the unique identifier of a material. Another example could be a sales area (which is a core organizational structure in the sales module of SAP). The sales area is uniquely identified by the combination of the sales organization, the distribution channel and the division. In conclusion the sales area class should have three attributes or, even better, one attribute being a structure with three components. Reports should not have more than a handful (5 absolute max?) of global data declarations.

3. As discussed, business logic should work with business ‘things’ meaning instances of classes. Let me try to explain. We talked about the material class which is an object that represents a material. An instance of that class could be material 12345 or material ABC2. An instance is a specific example of a type of thing. In the same way sales area 4000/10/00 could be an instance (example) of a sales area. Good code will operate on instances. But it is also possible to write OO code that is static. Static code does not need instances and is therefore hard to understand and to be avoided at all cost.

4. Class methods should be single purpose and should have a maximum of three importing parameters (ideally none or one) and usually one returning parameter. I often see methods receiving more than five importing parameters because the programmer is not using classes properly. Classes are still often used as pseudo-function groups by programmers who have not grasped the principles of object-oriented thinking. Consequently, they still write procedural code within the object oriented framework, using tons of attributes and static code and frankly making a mockery of object orientation.

5. Because all code blocks are kept small and single purpose, it becomes possible to give them clear meaningful names. The same goes for the few variables and parameters (we should be using few). There has been a debate ever since the beginning of ABAP coding around prefixes. The big news here is that in almost all cases you don’t need them. They are clutter. If you see them get rid of them. How often have I seen variables like lt_tab. That means nothing. I would much rather see a variable named sales_orders. This not only tells me what information that variable holds but also that it is a table or a list because of the plural naming. And I do not need to make it clear that this is a local variable as I hardly use global variables anymore. The only exception is the global data structure needed to pass data to a screen.

OO. Ohhhhh. :(

OO stands for object oriented. It means that you write code around objects. For example:  An object could be a customer or supplier or a product or a delivery or a sales order or any other thing that has a unique identity. In Abap OO, when you create your own objects (called classes), their name has to start with the letter Y or Z. So a good name for a class could be ZCL_MATERIAL. A class name should contain a noun because it pertains to a thing (tangible or intangible) In SAP, the material is uniquely identified by means of a material number and this number should be kept in the attribute of that class. Any business logic that applies to materials can be kept inside the zcl_material class in logic blocks called methods. For example: You could have a method called get_stock_quantity. This method would return the number of pieces available of that material. A good method name contains one verb because it pertains to an action/operation/activity.

You can then do things like this

MyMaterial = new zcl_material( 12345 ).

If MyMaterial->get_stock_quantity( ) = 0

Message MyMaterial->get_name( ) && ‘ is out of stock’.

Endif.

This is reusable code consisting of reusable simple and single purpose building blocks. That is one of the key ingredients to high quality code. Code that is written in this style reads fairly easily and is understandable for testers and business consultants but also for the next programmer. This is extremely important to guarantee business continuity in a world where many programmers do short term assignments and then move on.

[WARNING: a rant follows]

If you are handed ABAP code that you cannot easily read, it is BAD code. Reject it! Do not put up with it. Tell the programmer to do a better job or if you are the next programmer, make it clear to your superiors that you have inherited BAD code and that enhancements to the code will take more time (times 3 is a good starting point) than one would typically expect and that you cannot give any guarantees on your work and that they will have to do extensive testing including regression testing. Do yourself and the rest of the SAP world a favour and speak up!

Something must be done

 After 25 years working on Abap code it’s got to be said: oh boy! is there a bunch of abysmal code out there.

There’s a lazy coder’s website and tik tok feed which is all very funny but also tragically close to reality. I can’t believe the average abapper gets paid as much as he/she does when de average quality of code I’ve come across is atrocious. Wouldn’t it be fair to tie code quality to wages? Well I think it’s the only way to stop abappers from being as sloppy and unprofessional as they are being today.

I’m obviously not out on a charm offensive with my peers. I’ve had to deal with so much garbage I cannot keep quiet any longer. Something must be done.

My current thinking is that we need to give IT managers, PM’s, testers, team leads, etc… a means to rate the ABAP code that they are handed, and provide feedback to the developer and even reject code that simply doesn’t live up to certain standards. I also think the abapper needs a place where he/she can skill up to raise the quality of the work.

So we need a place to upload code objects and perform quality inspection. The inspection must be based on a set of intelligent rules. So we need those rules.

Obviously I’m aware of the standard tools and whilst I can see the merit in using them and following the guidelines they provide, they are hugely insufficient in my opinion.