Clean Code
The term Clean Code was coined by Bob C. Martin and his book of the same name. Shortly after the book was published, Ralf Westphal and I Clean Code Developer initiative and compiled 45 principles and practices. Clean Code, the book, was a stimulus for us to deal with the topic. We drew on various sources and some of the principles were already discussed in the 1970s. Here you can find, for example a PDF from Parnas from 1972 on the idea of modularization.
What do all these trends have in common? The aim is to linearize the course of costs, as shown in the following figure.
Whether we talk about clean code, clean code developer or software craftsmanship, the core issue is always to make software projects manageable by keeping costs linear instead of increasing exponentially.
Principles and practices
Principles and practices help us to do this. Here is an example: If we ensure in the code that a method or class has exactly one task, it becomes easier to understand the code. This ensures that Single Responsibility Principle (SRP) for a linearization of the cost curve. Code that we understand easily is easier to change or add to. The same applies to practices. For example, we recognize through Continuous Integration problems in the code more quickly because everything is regularly integrated. Practices also contribute to the linearization of costs.
Values
But this is where it gets exciting: does this mean that the principles and practices must always be adhered to? Are they the top priority? The answer is obviously no. At the top of the list are the Values. For example, it is about Changeability or Correctness. How these values are achieved is only the second question we ask. The answer is often to adhere to a principle or apply a practice. Here we are close to the concept of dogma.
According to Wikipedia the term Dogma in antiquity "the decree issued by rulers and thus not to be questioned". Obviously, we should not see principles and practices of software development as a regulation that has been issued by someone and is not to be questioned. Nevertheless, the question arises in detail as to whether, for example, principles should never be violated. Is there any leeway here? Are the Clean Code Developer principles and practices an opinion that can be followed or not?
Clean code training
Closed company courses
We conduct all seminars as closed company courses for you.
If you are interested or have any questions please contact us.
Necessity instead of dogma
Of course, the composition of the Clean Code Developer building blocks is somewhat influenced by our views. This cannot be completely avoided. For example, TDD is deliberately missing and only test-first is mentioned. I have already written about the reasons for this here (https://ccd-akademie.de/tdd-vs-test-first/). Nevertheless, our compilation provides a number of building blocks that lead to the overall goal of achieving the values of changeability and correctness. Should the building blocks now be viewed dogmatically and always adhered to? No. A differentiated approach is required. As a guide, it is imperative to think about the principles and check them in the code review. It is not a question of dogma, but of necessity. If we do not take the principles and practices into account, the increase in costs will be exponential. As this is not acceptable to our clients, following clean code is a necessity.
Clean code is a necessity. If you don't work according to the rules of the art, you will quickly fall behind.
Conclusion
The good news is: relax. The principles do not have to be adhered to dogmatically. But the other message is: clean code is a necessity. Sooner or later, at least in a competitive environment, it won't be enough to just bang out your code. Principles must be observed, practices must be introduced and practiced in the team. In every situation, you have to weigh up what is important at the time. Sometimes a principle must be adhered to in every case, sometimes other things take priority. A dogma might even be simpler, but its effect would be too simple. Just blindly adhering to any principle does not lead to the goal. A team needs a clearly structured way of working. This process must ensure that all important steps are taken that lead to high-quality code.
P.S. The following tools may be able to help you:
English 
German
2 thoughts on “Clean Code ist kein Dogma”
Pingback: 4 reasons not to write clean code - CCD Akademie GmbH
Pingback: 7 reasons for software companies to book a Clean Code Training - CCD Akademie GmbH