Tips From The Book Every Programmer Should Read

To be a programmer isn't just about to write code, but to write good and maintainable code. There is a must-read book that companies are paying their employees to read. And this is the book every programmer should read.

To write code that other programmers can understand is a hard task that only 20% of the programmers have. When you are writing software you can't only think if the machine can read, but also humans can.

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — Martin FowlerPhoto by Claudia on Unsplash

The book was written by Robert "Uncle Bob" Martin and it's called Clean Code: A Handbook of Agile Software Craftsmanship. This book explains more of the concept of programming for the code readers. This reader may be:

• The future you
• Your co-workers
• The machine

You have to write code that these three can understand or maintain.

Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way.

And how to code like a clean coder? There are some principles I'm going to list that will help you and convince you to read this awesome piece.

1. Write meaningful names

Variables, classes, functions and methods must be named semantically. Don't abbreviate names and name your code with meaning.

// bad :(def dvd(v1, v2)  return v1 / v2endres = dvd(10, 2)

// good :)def divide(dividend, divisor)  return dividend / divisorendquotient = divide(10, 2)

By giving more semantics to your code, you'll be able to understand it in your next editing session.

Apart from meaningful names, a clean coder will also write searchable names, such as:

// bad :(wait(foo, 86400000)

// good :)MILLISECONDS_IN_A_DAY = 86400000;wait(foo, MILLISECONDS_IN_A_DAY)

2. Don't add unneeded context

If you are writing a method or field inside a class, for instance, you don't need to refer the class context in the method/field name.

# bad :(class Person  property :person_nameend

# good :)class Person  property :nameend

3. Let your code speak

Good code over comments. That's a rule. Comments are necessary, but if your code explains itself, you don't need comments.

Comments can be evil

I'm sure they can…

# always returns truedef available?  return falseend

Commented code can be hard to read

In a quick code review, a commented code line can mess everything up.

employee.workboss.promote(employee)# employee.partyemployee.work

Why should you read Clean Code?

Programmers spend more time reading code than writing. That's a fact. To read code can be confusing if the code base is bad written, obsolete or legacy. To reduce the confusion and time lost, there are some companies paying their employees to read this book.

By teaching how to write software well, Clean Code is creating a huge group of programmers that care about what they are writing and who's going to read it: the clean coders.

Apart from semantics, Martin also talks about error handling, how to read code and so on.

If you are convinced to buy this book, check it out on Amazon.com.

Thank you for reading! Don’t forget to follow me on Medium and LinkedIn.

Tips From The Book Every Programmer Should Read was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.