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.
No comments:
Post a Comment