How to write Clean Code?

Lessons Learned about Clean Code book of Uncle Bob
Luan Nguyen
Luan Nguyen
Oct 12, 2020 · 6 min read

Master programmers think of systems as stories to be told rather than programs to be written  — Uncle Bob.
Clean Code book of Robert C. Martin (Uncle Bob) helps me enhance my coding skills and make remarkable in my career path. That's the reason why I want to share my lessons learned and summarize the main points of the book, I think it very useful to you.

Table of Contents:

  • Introduction to Clean Code book.
  • Main points what I takeaways:
    • What is Clean Code?
    • Write meaningful Names
    • Make a Function short and readable
    • Should you comment on bad code or rewrite it?
    • The benefit of Unit Test, Test Driven Development (TDD)
  • Conclusion

About the Clean Code Book

Clean Code book — A Handbook of Agile Software Craftsmanship, is a must-read book for developers, especially when you want to be a better software developer. 
This book explains not only what is the clean code, but also how to write good code and how to transform bad code into good code.

Clean Code


About the Author
Robert C. Martin, commonly called Uncle Bob, has been a software professional since 1970 and author of many famous books as The Clean Coder, Clean Architecture.


What is Clean Code?

Have many definitions about Clean Code by expert programmers asked by Uncle Bob:

Bjarne Stroustrup, inventor of C++ and author of
The C++ Programming Language:
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.

Bjarne Stroustrup

Grady Booch, author of
Object Oriented Analysis and Design with Applications:
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.

—  Grady Booch

“Big” Dave Thomas, founder of OTI, godfather of the Eclipse strategy:
Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names.
It provides one way rather than many ways for doing one thing. It has minimal depen- dencies, which are explicitly defined, and provides a clear and minimal API. 
Code should be literate since depending on the language, not all necessary information can be expressed clearly in code alone.

Based on the above some definitions, the main Characteristics of Clean Code includes:
  • Elegant: Clean code is pleasing to read and the reading should make you smile.
  • Readability: Clean code should read like well-written prose.
  • Simple: Do one thing with the Single Responsibility Principle (SRP).
  • Testable: Run all the tests.

Meaningful Names

There are only two hard things in Computer Science: cache invalidation and naming things.   — Phil Karlton
  • Everything in an application has a name, from variables, functions, classes, modules, to packages, source files, directories.
  • Names are the powerful way you communicate your code’s intent to developers who read your code, including yourself. 
  • Choosing good names takes time but makes your code better and cleaner. It makes your code easy to read by other developers, as well as yourself in the future.
by Tim Ottinger


RULES TO WRITE GOOD NAMES:
Use intention-revealing Names
That means choosing names that reveal intent, the name should tell you why it exists, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent. It makes your code easier to understand and change later.
# bad 
t = Date.today # the name t reveals nothing.
# good
today = Date.today

Use Pronounceable Names
If you can’t pronounce it, you can’t discuss it without sounding like an idiot. This matters because programming is a social activity. 
# bad 
ymdhms = Time.current # year, month, day, hour, minute, second
# good
today_timestamp = Time.current

Pick One Word per Concept
Be Consistent, for example as don’t use fetch, retrieve or get  for the same concept in different classes.

Class Names
Classes should have nouns or noun phrases names like User, Account, Book, Author.

Method Names
Methods should have a verb or verb phrase names. Examples: createUser, deletePhoto, save.


Functions

  • How to write a function easy to read and understand?
  • How do you make a function communicate its intent?
There are some best practices below help you write good functions are readable and changable:

Small
  • The first rule of functions is that they should be small. 
  • The second rule of functions is that they should be smaller than that.

Do One Thing

Function Arguments
  • Functions should have < 3 arguments.
  • The ideal number of arguments for a function is zero. Next comes one, followed closely by two. Three arguments should be avoided where possible. 

Don’t Repeat Yourself (DRY)
Duplication is a problem in software. Many principles and best practices have been created to reduce duplication code.

Use a Descriptive Names
Same with rule meaningful names which explained in the above section.
Master programmers think of systems as stories to be told rather than programs to be written — Uncle Bob.

If you apply well these above rules, your functions are readable, easy to understand, nicely organized and to tell the story of the system.


Comments

  • Comments don't make up for bad code.
  • Explain your intent in code.
Don’t comment bad code, rewrite it!
— Brian W. Kernighan and P. J. Plaugher


Unit Tests

Test code is just as important as production code.
The Test Driven Development (TDD): is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests, only.

Uncle Bob describes 3 Laws of TDD:
  • First Law: You may not write production code until you have written a failing unit test.
  • Second Law: You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
  • Third Law: You may not write more production code than is sufficient to pass the currently failing test.

The Cycles of TDD by Uncle Bob

Tests are very important to an application as the production code is, because it makes your code is clean, flexible and maintainable. If you have tests, you do not fear change to the code and reduces bugs.
Unit tests help me get more deep sleep!

Conclusion

In this article, I already introduced to you about Clean Code book, and best practices to help you write good code. It’s very important for every developer who wants to be remarkable in the career path!