In the first article I talked about the why's and what's. Now let’s dig a bit deeper and take a more theoretical approach in this one. I promise this will be the only one in the series.

CCD is built upon a set of rules and principles that are evaluated based on the effects they will have by applying them in your code. But before we go any further, I will break my promise and show you an example of "how not to write ABAP code".

I picked up this code snippet to show some very straightforward “DON’Ts” that we stumble upon more than often in SAP. This is a classical example where multiple people worked on the same piece of code and applied their own style over the years. It doesn’t even matter at this point what this Function Module does. First thing first, the comments. It just gouges your eyes out. There are two languages here, German and English.

SAP is pure Wurst mit Sauerkraut at its core, but not all SAP Developers are German-speaking individuals. This makes it unwelcoming. Even worse, it is hard to follow code in which you have to switch between two or even three languages when reading its comments. You know, they should be there to help, not make you cry. Secondly, the code formatting. Uppercase, lowercase … you never know which is the correct style. There is another issue regarding code writing, that for a SAP developer comes naturally but for, let's say, a Java Developer would be a complete nightmare. I can even hear some asking: "What the hell are all those variables?!?".

There is no naming convention and all those VBAKs look like gibberish to an untrained eye. One has to suffer the thousand slashes of "Sales and Distribution" to be worthy to venture in its realm. I might get some perplexed looks for the next issue, that is common practice in SAP. The humongous number of code lines in one development object. If you only have 200 lines, you are not a true SAP developer. I worked with objects that were over 4000 of lines of code. "The One" that does everything. Often you will find in these huge development objects duplicate code or code that just isn’t executed anymore. No one knows for sure if that old piece is still important. So to play it safe, it is left there for others to contemplate on it.

Ok, before moving further, here is a small bonus. If Petr says this is better, who are we to defy him?

There are four values defined in the Clean Code literature and each of them will appear in different variations. They should always be considered when building a software product.

  • Evolvability
  • Correctness
  • Productive Efficiency
  • Continuous Improvement

Evolvability - represents how easily your software embraces changes. Code needs to be maintained without (or with as few as possible) headaches. It needs to have the ability to adapt without too much effort. More than often, you will need to add a parameter to your method, enhance the main functionality of a product, expose the API to other products, so on and so forth.
Now comes the question: "Why should we take this into account?" Because we, as developers, should look at code not only from the technical point of view. There is also this hidden “business” side of it too. Depending on the industry of your company, this can be seen more as a cost (in case the software is made for in-house usage) or profit (the software product will be sold to other clients). But in the end it is a product, something that will bring value to your company.
By taking into consideration the evolvability of the code from an early phase of a project, you will enable its enhancement and adaptation over longer periods of time with less effort. This will make customers more inclined to buy and use our software for a longer time.

Correctness - the software we deliver must work ... correctly. No hidden treasure here. This can be easily identified by management as the quality of the product. Easy, right? It has to work as intended, to have all the desired functionalities, plus it needs to be performant. The dream of each project manager. But let me tell you, this doesn't happen in a lean way or even at all. A software product isn't just a piece of code that works. Missing documentation, no unit tests, misunderstood functionalities, ambiguous acceptance criterias, all of these, are elements that are often part of the product. There will always be something or someone to blame for it, but we should all know by now that the main culprit is time. And time is money. And cutting corners saves money but only temporary.

Production Efficiency - There are a lot of factors to be taken in consideration here, but the most important is development time. If the development time is higher, the price of the software will be higher too. And this is not only about creating the “perfect” software. Yes, functionalities will have to be left out or refactoring will not be an option. However, there are other issue to be tackled, like ambiguous code, unit tests, guidelines, everything that can guarantee a lean development phase. Moreover, production efficiency takes into consideration errors and bugs you will need to fix during the implementation. Writing code as fast as you can, will only bring up unwanted issues and affect its efficiency.

Continuous Improvement - this is a tricky one. Most of the documentation out there will tell you to embrace reflection. But what is that? You won’t start now doing mindfulness and transposing yourself to be one with the code after each programming session. I didn't find yet a job as Code Yogi.
In my opinion, this means to have an open mind about your code and your project. The first idea you have isn't necessarely the best. Pair programming, code reviews, scrum meetings etc., all represent tools to gather more insights. How can I do it better? Where did it go wrong? What did I learn from this? All of these are questions that a programmer should ask himself every time.

These values should infuse our work as programmers. In the next series of CCD I will touch on them whenever it is necessary. However, I will continue with more practical and applied approaches. The first one to tackle will be one loathed by everyone: naming conventions.