You are a developer, do you want to be a better developer?
What is the difference between good code and bad code?
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).
Have many definitions about Clean Code.
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."
How to create good names ???
- Should not:
Improve the readability of your code.
"Master programmers think of systems as stories to be told rather than programs to be written."
Follow the rules:
"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 =))
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.
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 :)