Clean Code and Design Principles Complete Guide
- Introduction to Clean Code and Software Design Principles
- Writing Meaningful Variable Names
- Designing Good Functions and Classes
- Software Design Principles - I (DRY, YAGNI, KISS, etc)
- Software Design Principles - II (Abstraction, Extensibility, Cohesion)
- Software Design Principles - III (SOLID Principles)
Code is clean when it is easily readable by developers other than the original author as well.
Writing clean code might seem like an overhead at the beginning. But it allows us to maintain and develop a piece of software fast in the long term. I've created this series of articles by building on the ideas discussed in the book 'Clean Code'. Clean Code is the bible of good coding practices written by Robert C. Martin (Uncle Bob).
Why should you write clean code?
We as developers write code for the computer to understand. At the same time, our code is not going to remain the same as we update the business logic or add new features. Our code might get updated by other developers as well. Hence, we must write code in such a way that other developers can also read and understand it.
How to write clean code?
We can write clean code by following a set of guidelines known as Software Design Principles. Software Design Principles is a set of guidelines proven to work over the years.
A few of the broad guidelines to write clean code are:
- Give meaningful names to variables, functions, classes, and other entities in the code.
- Create functions that are small and do a single thing.
- Encapsulate related data and functions into small independent classes.
- Structure the code for better readability. Keep related code together and keep the lines smaller.
- Enhance readability with proper comments.
- Write readable, fast, independent, and repeatable tests.
I've listed down some of the most popular and useful design principles. You should try to enforce them in your code with every iteration.
- Avoid code repetitions (DRY).
- Keep the code simple (KISS).
- Hide implementation details (Abstraction).
- Keep the code extensible (Extensibility).
- Keep the code modular with minimal overlap (Separation of Concerns).
- Each module should do only one thing (Curly's law).
- Avoid unnecessary functionalities (YAGNI) and preoptimization (the root of all evil).
- Stay consistent and avoid surprises in the code (Principle of least astonishment).
- Make the code better than how you found it (Boy-Scout Rule).
There are many more guidelines/principles. We will be discussing the most popular principles in the upcoming sections/articles.
A set of principles known as SOLID Design Principles have been derived from various design principles. The SOLID Design Principles are:
- The Single-responsibility principle: "There should never be more than one reason for a class to change." In other words, every class should have only one responsibility.
- The Open–Closed principle: "Software entities ... should be open for extension, but closed for modification."
- The Liskov substitution principle: "Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it".
- The Interface segregation principle: "Many client-specific interfaces are better than one general-purpose interface."
- The Dependency inversion principle: "Depend upon abstractions, [not] concretions."
We will learn more about the SOLID principles in further articles.
References: Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin (Uncle Bob)
---
Read next
