Clean Code Cheat Sheet - Why Clean Code, Smells, Design Principles & Practices

Nov 1, 2026

Uploaded by Terk

Clean Code Cheat Sheet outlines why clean code matters for team-wide understandability, readability, changeability, extensibility, and long-term maintainability without accumulating excessive technical debt. It lists common code smells such as rigidity, fragility, immobility, unnecessary complexity, needless repetition, and opacity, explaining how they increase effort and defect risk. It then summarizes core class design principles, packaging cohesion and coupling rules, and general, environment, dependency injection, and design practices for building, testing, and structuring software effectively.

LanguageEnglish

CategoryTechnology

FormatPDF

Pages4

Reading Time10 min

AccessFree to download

Why Clean Code

Smells

Class Design Principles

Package Cohesion

Package Coupling

General Rules

Environment Practices

Dependency Injection

Design Guidelines

C lean Code Cheat Sheet |
Why Clean Code
Code is clean if it can be understood easily – by everyone on the team. With understandability comes readability, changeability, extensibility and maintainability. All the things needed to keep a project going over a longtime without accumulating up a large amount of technical debt. | | |
Smells
Rigidity –
The software is difficult to change. A small change causes a cascade of subsequent changes.
Fragility –
The software breaks in many places due to a single change.
Immobility –
You cannot reuse parts of the code in other projects because of involved risks and high effort.
Viscosity of Design –
Taking a shortcut and introducing technical debt requires less effort than doing it right.
Viscosity of Environment –
Building, testing and other tasks take a long time. Therefore, these activities are not executed properly by everyone and technical debt is introduced.
Needless Complexity –
The design contains elements that are currently not useful. The added complexity makes the code harder to comprehend. Therefore, extending and changing the code results in higher effort than necessary.
Needless Repetition –
Code contains exact code duplications or design duplicates (doing the same thing in a different way) . Making a change to a duplicated piece of code is more expensive and more error-prone because the change has to be made in several places with the risk that one place is not changed accordingly.
Opacity –
The code is hard to understand. Therefore, any change takes additional time to first reengineer the code and is more likely to result in defects due to not understanding the side effects.

Class Design
Single Responsibility Principle (SRP) +
A class should have one, and only one, reason to change.
Open Closed Principle (OCP) +
You should be able to extend a classes behaviour without modifying it.
Liskov Substitution Principle (LSP) +
Derived classes must be substitutable for their base classes.
Dependency Inversion Principle (DIP) +
Depend on abstractions, not on concretions.
Interface Segregation Principle (ISP) +
Make fine grained interfaces that are client-specific.
Classes Should be Small +
Smaller classes are easier to grasp. Classes should be smaller than about
100 lines of code. Otherwise, it is hard to spot how the class does its job and it probably does more than a single job.

Do stuff or know others, but not both
Classes should either do stuff (algorithm, read data, write data,…) or orchestrate other classes. This reduces coupling and simplifies testing.

Package Cohesion
Release Reuse Equivalency Principle (RREP) +
The granule of reuse is the granule of release.
Common Closure Principle (CCP) +
Classes that change together are packaged together.
Common Reuse Principle (CRP) +
Classes that are used together are packaged together.

Package Coupling
Acyclic Dependencies Principle (ADP) +
The dependency graph of packages must have no cycles.
Stable Dependencies Principle (SDP) +
Depend in the direction of stability. | Stable Abstractions Principle (SAP) +
Abstractness increases with stability

General
Follow Standard Conventions +
Coding-, architecture-, design guidelines (check them with tools)
Keep it Simple, Stupid (KISS) +
Simpler is always better. Reduce complexity as much as possible.
Boy Scout Rule +
Leave the campground cleaner than you found it.
Root Cause Analysis +
Always look for the root cause of a problem. Otherwise, it will get you again.
Multiple Languages in One Source File –
C\#, Java, JavaScript, XML, HTML, XAML, English, German …

Environment
Project Build Requires Only One Step +
Check out and then build with a single command.
Executing Tests Requires Only One Step +
Run all unit tests with a single command.

FAQs

Why does the document emphasize clean code?

Clean code is presented as easy for the whole team to understand, which improves readability, changeability, extensibility, and maintainability while reducing technical debt.

What are the main categories of code smells listed?

The document groups smells such as rigidity, fragility, immobility, viscosity of design/environment, needless complexity, needless repetition, and opacity, each describing how changes become costly or risky.

Which class design and packaging principles does it cover?

It covers SRP, OCP, LSP, DIP, ISP, small classes, and separation of responsibilities. For packaging it includes cohesion rules (RREP, CCP, CRP) and coupling rules (ADP, SDP, SAP).

What engineering practices are recommended beyond design rules?

Recommendations include standard conventions, KISS, root-cause analysis, using a source control system, continuous integration, single-step build/test, and dependency injection to decouple construction from runtime behavior.

Nov 1, 2026

Uploaded by Terk