Clean Code Development – Red and Orange

The last blog post was about the values, principles and practices of clean code development. The rules presented there form the basis for clean software development. Only those who really internalize these rules can call themselves a clean code developer after a certain period of time. It is not about memorizing the rules, but about actually living the value system, principles and practices.

The different degrees of clean code development

To support this process of internalization, the Clean Code Development value system is divided into different levels. These so-called levels are to be climbed gradually by developers. However, not in the form of a process that approaches a goal step by step, but as part of recurring stages. The individual grades of Clean Code Development are therefore run through repeatedly in order to support a continuous learning process.

There are a total of 5 development stages, which are color-coded. Stage 1 is marked in red and stage 2 in orange. The colors yellow, green and blue characterize the other 3 stages. It should be noted at this point that the grades do not express a value. People working on the blue level are not “better” than developers who are currently on the yellow level. The development levels merely serve to divide the entirety of the value system as well as the principles and practices into individual, easily digestible learning stages.

Grade number 1: Red

The red level teaches the essential elements of the Clean Code Development value system, principles and practices. This first level is not so much about software development principles as it is about building a fundamental understanding of software development according to the clean code approach. At the same time, the red level is structured in such a way that all developers can get started with minimal effort.

Below is a simplified overview of the red level principles and practices that are important for implementing clean code.

Principles

Don’t Repeat Yoursef (DRY)Repetition of code should be avoided. Any duplication of code or actions leads to errors more quickly and also makes maintainability more difficult. The DRY principle is designed to prevent exactly that.

Keep it simple, stupid (KISS)Code should always be easy to understand. Therefore, simple, clear and easy-to-understand solutions should always be preferred. Make things as simple as possible during development and stop complicating processes etc. unnecessarily.

Beware of Premature OptimizationBeware of optimization! Optimizations are always associated with costs and are rarely necessary or useful. Those who act cautiously here often save valuable resources for what really helps the customer / the project.

Favor Compositio over Inheritance (FCoI)The principle states that compositions should be used instead of inheritance, so that classes are separated from their algorithms and their details in order to be able to change the behavior of a class at runtime.

Integration Operation Segregation Principle (IOSP)When developing code, a clear distinction must be made between different development methods. Either only logic is used, i.e. transformations, control structures or API calls, in which case the procedure is referred to as an operation. Or no logic is used at all and instead only calls to methods with the same code base are used, in which case the procedure is referred to as integration.

Practices

Boy Scout RuleThe Boy Scout Rule says: Always leave a place in a better condition than you found it. This concept can also be applied to software development. Visible errors in the code should be eliminated as quickly as possible before they become a major problem.

Root Cause AnalysisThis thorough analysis is used to look directly for the source of problems in the code and not to start dealing with the problem at the end of development.

Version Control System: The version control system is a mandatory requirement for every developer. The system takes away the fear of doing something wrong or breaking something and thus enables the courageous use of all the principles and practices of clean code development.

Simple refactoringsThis practice is designed to restructure software while retaining its functionality. Two simple refactoring patterns are, for example, the extraction of methods or the renaming of variables.

Daily Reflection: Active learning, improvement and progress can only be achieved if there is daily reflection on what has been achieved. Reflection should therefore become a fixed part of the day in the form of a recurring appointment.

Grade number 2: Orange

While the foundations for the continuous improvement process are created in level 1, level 2 is about applying some fundamental principles to the code and gaining initial experience with the automation of processes. In this phase, automation is used in particular to check for correctness.

Below you will find a simplified overview of the principles and practices of the orange level.

Principles

Single Level of Abstraction (SLA)A line of code can be at different levels of abstraction. However, for code to be easy to read, only one level of abstraction should be used within a method. Otherwise, it is difficult to distinguish essentials from details.

Single Responsible Principle (SRP)This principle states that a class should only have one task/responsibility. The more classes have to be adapted in order to optimize a function, the higher the susceptibility to errors.

Separation of Concerns (SoC)This is closely related to the previous principle and means “separation of concerns”. Accordingly, the principle states that several concerns should not be combined in one class.

Concerns in this case are defined as supersets of responsibilities. Ideally, each of these responsibilities consists of exactly one concern. However, several concerns are often mixed together in one responsibility. As this is usually technically unavoidable, the principle does not state that a responsibility may only consist of one concern, but that the concerns should be separated. Within a method, for example, it should be clearly recognizable that there are several concerns. Furthermore, the concerns should not be scattered throughout the method, but grouped in such a way that it is clear what belongs to a concern.

Source Code ConventionsThe principle defines guidelines that help to improve software quality. These guidelines include, for example, naming rules, comments, declarations or white spaces.

Practices

Issue TrackingIssue tracking describes the process from the recording to the elimination of errors or open issues.

Automated integration testsAutomated integration tests ensure that different components still work together even after a refactoring or extension.

Read, Read, Read: Many things in software development continue to evolve, such as software technology, methods, frameworks and tools. It is therefore necessary for developers to constantly educate themselves and read the latest magazines, books and blogs.

Reviews: Reviews increase the quality of the code. True to the motto: four eyes see more than two. Walkthroughs, technical reviews, peer reviews or inspections, for example, are conceivable.