Skip to main content

Book Review: Clean Code

Undoubtedly, one of the most popular books in software engineering, it teaches the fundamentals of software architecture, methods for organizing code, and is widely regarded as a must-read for any software developer. Written by Robert C. Martin, also known as "Uncle Bob," the full title of the book is "Clean Code: A Handbook of Agile Software Craftsmanship".


Key Takeaways

The book emphasizes a few important topics to pay attention to:

  • Readability: The code should be written in a meaningful manner that is easy to read and understand. It emphasizes the importance of simple, short, clear naming for variables, functions/methods, classes, and other structures for code organization (folders, namespaces, packages), as well as maintaining consistency in naming throughout the application. This also reduces the need to write comments in the code, as the code itself should be self-explanatory. Additionally, it's important to avoid using global variables, as they often introduce unseen or difficult-to-track dependencies, making the code harder to maintain and debug.

  • Simplicity: Keep it simple and avoid the trap of overengineering to show how smart you are ☺Good code is the code that can be easily maintained.
  • Modularity: Code should be organized in smaller units easy to change and refactor. Also here important to mention is to make modules based on single responsibility priciple, meaning that one module/unit should not be resposible for more than one task. This principle should be upheld at all architectural levels, considering the appropriate granularity of each module. Granularity, in other words, refers to the abstraction level of a module/unit (such as a function, class, package/namespace, library, etc.).
  • Testability and Refactoring: These two topics are somehow related. In the process of writing the code that is easy to test, we are constantly refactoring it. Once when all tests are passed, we ensure that we can go with further refactoring if needed, because we have something that backs up the functionality and ensures it won't be broken.

Conclusion

Although there is much more to discuss regarding this book, it wouldn’t be suitable for a single blog post. That’s why we’ll keep it short and simple. One important thing to remember is that the book is not a set of rigid rules, but rather a collection of best practices for writing efficient and maintainable software. The main focus, after efficiency, is maintainability, since we, as developers (except for the lucky ones ☺), spend much more time reading old code than writing new one.

Comments

Popular posts from this blog

Design Patterns: Singleton

Tyipically the first design pattern most people learn, often wrongly ☺ To give an introduction, we can say that singleton is one of the creational design patterns which ensures only one class instance with single point of access thru entire application.  Because it is relatively simple to implement, the Singleton pattern is sometimes misapplied in situations where it is not the most suitable choice. When to use it? Here are the few examples of corrent usage of singleton: Configuration Management  Centralized configuration settings for consistent use thru entire application Caching Maintaning  Single istance of cached objects for easy and fast acces Logging  Ensure unified mechanism to avoid duplication of log files, formats, etc Global State Management  Centralized management of the state which is needed to be shared accross the application Resource sharing  Thread pools, database connection, I/O operations When not to use it? On the other hand, here are fe...

Design Patterns: Builder

This is also, like a Singleton , one of the creational design patterns. It provides the way of creating complex objects step by step by simple chaining and every particular step is independent of other steps. Let us dive into the real example of usage. For showing purpose we have created an example in C# which creates simple SQL queries using described pattern.  using System; using System.Text; namespace BuilderPatternExample { public interface ISqlQueryBuilder { ISqlQueryBuilder Select(string columns); ISqlQueryBuilder From(string table); ISqlQueryBuilder Where(string condition); ISqlQueryBuilder OrderBy(string columns); string Build(); } public class SelectQueryBuilder : ISqlQueryBuilder { private readonly StringBuilder _queryBuilder; public SelectQueryBuilder() { _queryBuilder = new StringBuilder(); } public ISqlQueryBuilder Select(string columns) { ...

Why Do Employers Lie In Interviews?

This is a very common subject that many of us have already experienced. But when you realize that half of what has been said at interviews is actually a lie, you are already at least six months in the company, you have already started some project and it wouldn’t be appropriate to leave the company at that moment. Why is this happening? First of all, let us see how the usual interview process looks like in software development companies. First round interview in most of these companies is an interview with HR. This is the first insight about the company. A person who works in HR is usually someone who, in most cases, doesn’t understand what the software is and how the software development process goes. Big respect to those companies where HR knows these things. This phase usually contains some standard questions about your personality, what do you like about the company, how this company is something that you are actually looking for, where you see yourself in five/ten  years etc… ...