Freely available Clean Code Developer articles from dotnetpro
The dotnetpro, namely the editor-in-chief Tilman Börner, has made the first four articles of the Clean Code series freely accessible. Below is a brief description of what each article is about. You will also find a link to each article.
In principle, the devil is in the detail
The Clean Code Developer Principles help us to build and maintain structures in code. Each has its own background, its own message and is expressed in the code in its own way. Admittedly, with 45 principles and practices, it is easy to think that there are overlaps in content and that some may be interchangeable.
Let's take the two principles Single Responsibility Principle (SRP) and Integration Operation Segregation Principle (IOSP). In terms of content, it can be argued that the IOSP is a specialization of the SRP. The separation of integration and operation means a separation of responsibilities. Operations may only contain details, i.e. expressions, framework and runtime APIs. Integrations, on the other hand, have the responsibility to call methods of their own domain. From this, it can be concluded that the IOSP is about the same thing as the SRP. If you take a closer look, you realize that this is not the case. This is because the IOSP does not state that an operation can only have one responsibility. Nor does it have to, because that is where the SRP comes in. Conversely, the SRP does not explicitly state that the separation of integration and operation is a separation of responsibilities. Only the IOSP makes this statement.
From this observation, it can be concluded that the principles actually overlap in terms of content. This does not mean that they are interchangeable, but that they complement each other. The SRP can be observed without taking the IOSP into account and vice versa. Used alone, both principles are a step forward for code quality. Together they make an unbeatable team.
Stefan Lieser has written another example on this topic in the dotnetpro article on KISS and YAGNI.
https://www.dotnetpro.de/planung/clean-code/kiss-yagni-2730355.html
Refactoring is good, control is better
Careful, there are also challenges in the consistent application of the principles. Principles overlap. If they are all observed, they complement each other. If they are not, the result may be that one principle is pursued and another principle is directly violated as a result. A small abstract example: In a refactoring, there is a function with integration code and operation code. We apply the IOSP and separate integration from operation. The resulting integrations implicitly fulfill the SRP. Operations, on the other hand, can fulfill more than one task and violate the SRP. This impairs the changeability. The code inevitably becomes more difficult to read and adding a new feature becomes more complicated. We also have a negative impact on correctness. An operation that fulfills more than one task cannot usually be tested well. The tests usually become unnecessarily complex. So when refactoring according to certain principles, also check that the others are adhered to.
You can find a concrete example of this challenge in the dotnetpro article "Don't repeat yourself! - What if you do?".
https://www.dotnetpro.de/planung/clean-code/don-t-repeat-yourself-2701511.html
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.
Speaking of complex tests and how the IOSP helps to prevent them
Let's look at the topic of dependencies, probably the biggest challenge of software development in terms of changeability and correctness. Lack of planning and unstructured implementation often lead to equally unstructured dependencies in the source code. These often become apparent when you try to write tests. Who doesn't know at least one method that could only be tested with the help of dependency injection and mocks? After all, if the DIP is used, the dependency can be passed from outside and replaced by a mock for the test case. That's good, isn't it?
Yes, because testability is achieved. And yet it rightly seems far more cumbersome than necessary. Because many methods can simply do without DI altogether.
The strategy is called IOSP and Stefan explains it in this article. Be sure to read it!
https://www.dotnetpro.de/planung/clean-code/dip-iosp-2718576.html
Black box vs. white box
The IOSP leads to good testability. Integration methods can be easily tested with integration tests, operations can be easily tested with unit tests. A good combination of the two gives us optimum test coverage. This is where the debate about black box versus white box tests usually starts in seminars. Questions often arise such as "Aren't operations private?", "How can I test them?" or "Shouldn't we only test public methods?".
Stefan has discussed the topic of black-box vs. white-box tests here in the blog already treated. You can also find answers to these questions and more in the following article by Stefan in dotnetpro. We hope you enjoy reading it.
https://www.dotnetpro.de/planung/clean-code/schwarz-weiss-liegt-menge-grau-2711296.html
English 
German