## DEV Community is a community of 662,276 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

EBANX

# The book every programmer should read

Vini Brasil
I am a software engineer working with Elixir, theology student, and musician based in beautiful Curitiba.

Writing code that any programmer who read can understand is a must-have skill for software developers. The fact is: only 20% of the programmers have the ability.

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — Martin Fowler

When I started caring about code readability I noticed that my code started to be:

• easier to maintain
• easier to refactor
• reusable
• consistent

# The book

Robert "Uncle Bob" Martin's "Clean Code: A Handbook of Agile Software Craftsmanship" is the clean coder programmer bible. This book talks about code, behaviour, automated tests and so on.

# Let's get practical! Writing meaningful names.

One of Clean Code chapters talks about meaningful naming. In this story, you are going to be the code reader. Take a look at this function:

``````def calc(n1, n2)
return n1 / n2
end
``````

Do you think `calc` is a good name for this function? Uncle Bob would say: no! Why?

1. `calc` is an abbreviation: don't!
2. Functions do something. It must be named with a verb.
3. Even I rename `calc` to `calculate`, it still be vague. We need to improve the semantics by giving the function name more meaning.

This function divides two numbers. `divide` is a good name for it.

``````def divide(n1, n2)
return n1 / n2
end

result = divide(1, 2)
``````

We still have problems with it. "n1" and "n2", the parameters, are not semantic. What if we call them "dividend" and "divisor"? The same thing to the "result" variable. It should be called something like "quotient".

``````def divide(dividend, divisor)
return dividend / divisor
end

quotient = divide(1, 2)
``````

Much more semantic!

If you are not convinced to read this book yet, take a look in this picture and buy this must-read book!

## Discussion (19)

It is a good read, definitely in the top 10, but I would not say it is THE BOOK, and also I would not recommend it for junior developers that are in their first 2 years of programming (as in they have bigger fish/books to fry).

Robert Schaap

I read it at the start of my second year and I'd actually agree with that. The book is amazing and will definitely improve how you write code, but the examples are written by an experienced Java programmer and some of them are quite hard to understand for beginners.

If you do decide to read it, don't be afraid to stick to the topics that seem relevant and skip ahead here and there (as I did). It's a great book to come back to after some time has passed and the appendix/summaries at the end are very helpful.

Jan Wedel

Hmm, interesting. Actually it’s among my personal top 3 of influential books and I’ll have every new developer read it in my team.

I read it when I was already an experienced developer. It was more about giving things names and good example that already did out of a gut feeling.

But I haven’t thought about how it it is received by inexperienced developers...

Is it just your feeling or do you have tales to people that actually had problems understanding it?

I did not tried to test it on juniors, it is common sense I guess.

It solves issues they do not encountered yet, do not understand so they will not apreciate.

They have bigger fish to fry: a language, paradigms, dev tools, how software works in general and how is developed and so on.

Jan Wedel

There’s surely a lot to learn, but juniors are actually able to learn a lot in a short amount of time.

Moreover, “common sense” doesn’t really count. That sounds like not allowing children to try something only because one think they won’t make it.

So for me, clean code next to testing is one of the foundations of high quality code and I’ll start teaching that as early as possible.

We do coding dojo’s every sprint so we actually practice what we preach :)

José Luis Larroque

Which one do you suggest instead ?

None, I think is specific, because every dev has its own gaps and knowledge.

For example Clean Code and Clean Coder goes hand in hand, covering complementary skills.

Before these the Pragmatic Programmer may clear the way into explaining what devs actually do.

There are 2 posts on dev.to with top 10, I think we can start from there, but all are equal important.

Ashley Maria

Learning to code first, then you can understand the "rules" and how/when to break them.

Omar Rodriguez

By that logic I guess you are trying to improve your blog post reading skills. 🤣

Scott Lovenberg

I also recommend, as supplements to Clean Code, The Clean Code Talks given at Google about a decade ago by Misko Hevery (Ref: youtube.com/playlist?list=PL-XjMWI...) and the classic Code Complete by Steve McConnell. I should note that I found myself disagreeing with a few items in the Clean Code Talks, but as our boy Freddy Brooks tells us, there's no silver bullet (Ref: en.m.wikipedia.org/wiki/No_Silver_...), so keep your mind open to the guidelines so you know when to use them as rules or break them completely; every code base has a history and point of view that must be understood before you can even begin to decide when to break the rules or enforce them.

Generally speaking, if you can't articulate a clear and very specific engineering trade off that you're making by not following the guidelines, you're probably best served by sticking to the safety of the best principles practiced in the books and videos mentioned here. That last bit is my own opinion, feel free to disregard if you have a clear and specific reason to. There's an art to everything, including science. ;)

Јован Хрњак

+1 for Code Complete, that one was a game changer for me.

Jason C. McDonald

I've mentioned it before, but "Dreaming in Code" by Scott Rosenberg is also something of a must read for coders. I bring it up here because it demonstrates the importance of clean coding (and good project management) principles through the chronicle of several coding disasters. Makes for a nice companion read.

Swarup Kumar Mahapatra

"Refactoring: Improving the design of existing code" by Martin Fowler is one of the better books.

The refactoring problems which he has addressed are real. The "catalogue" section of the book talks nicely about the steps (step 1, step 2, step 3 ... ) of each refactoring techniques.

The first edition was released in the year 2000 I think , using Java as language of choice.
The second edition has been released just recently , using JavaScript as language of choice

Doruk Kutlu