Clean Code - A Handbook of Agile Software Craftsmanship
You are a developer, do you want to be a better developer?
What’s more, you’ll be able to tell the difference between good code and bad code.
You’ll know how to write good code and how to transform bad code into good code.
The objective of the article summarizes some of the main chapters in the book so that you save time and have look quickly about Clean Code.
Clean Code includes 17 chapters from low-level (chapter 2 - 6) to higher level concepts (chapter 7 - 13) and case studies (chapter 14 - 17).
Chapter 1. What is Clean Code
Have many definitions about Clean Code. So Robert asked some very well-known and deeply experienced programmers what they thought.
Grady Booch said: "Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control."
Bjarne Stroustrup said: "I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well."
[Keywords for Clean Code]
Chapter 2. Meaningful Name
Names are everywhere in software. We name our variables, our functions, our arguments, classes, and packages. How to create good names ???
- Use Intention-Revealing Names
- Make Meaningful Distinctions
- Pronounceable Names
- Use Searchable Names
- Should not:
- Be Cute
- Pun (same word for two purposes)
=> Improve the readability of your code.
Chapter 3. Function
"Master programmers think of systems as stories to be told rather than programs to be written."
Follow the rules:
- The first rule of function is Small!
- Done one thing.
- Function Arguments (should < 3).
- DRY (Don’t Repeat Yourself).
- Descriptive Name.
How Do You Write Functions Like This?
If you follow the rules herein, your functions will be short, well named, and nicely organized. But never forget that your real goal is to tell the story of the system, and that the functions you write need to fit cleanly together into a clear and precise language to help you with that telling.
Chapter 4. Comment
"Don’t comment bad code—rewrite it."
- Comment do not make up for bad code.
- You will not use comment when you write a descriptive function or class.
Say NO with comment code =))
Chapter 5. Formatting
The purpose of Formatting is let’s be clear. Code formatting is important. It is too important to ignore and it is too important to treat religiously.
Code formatting is about communication, and communication is the professional developer’s first order of business.
A good software system is composed of a set of documents that read nicely. They need to have a consistent and smooth style. The reader needs to be able to trust that the formatting gestures he or she has seen in one source file will mean the same thing in others.
Chapter 6. Object and Data Structure
There is a reason that we keep our variables private. We don’t want anyone else to depend on them. We want to keep the freedom to change their type or implementation on a whim or an impulse. Why, then, do so many programmers automatically add getters and setters to their objects, exposing their private variables as if they were public?
- Law of Demeter: the Object Never Talks to Strangers.
- Objects hide their data behind abstractions and expose functions that operate on that data. Data structure expose their data and have no meaningful functions.
This is a great book for every developer who want to be a better developer.
Have you read Clean Code? Let me know what you think about this book in the comments.
I hope so this article is useful for you :)