There are plenty of books that talk about coding style. Art of Readable Code is one of them. There is quite a bit of debate among programmers what is correct and what is not.
I remember in my early days one of the senior developers was willing to code review a 4 function calculator I did. The list I got was longer than my arm. If you have followed my Noob to Pro series, I can tell you I was very much a Noob at this point.
My accidental start with clean code.
One of the things I noticed in the list was there was a clear distinction between things that were legitimately wrong and things that were opinionated-ly wrong. For instance, my variable names did not do Hungarian notation. In school they discouraged us from doing that. Ten years earlier they encouraged it in school. So he was saying do this, not that. I talked to him about it and realized that several of the items were stylistic concerns.
Some I adopted and use to this day. Others, I never adopted. I can tell you that couple of hours he reviewed my code really grew me as a developer. Deep in these reviews, where clean code principles I was being taught, all stealthy like. It was more than a bit humbling to realize how good my senior developer mentor was at moving me to the next level. As a result of his efforts, most of those lessons were already known to me.
With my story out of the way, lets get back on the review.
The good of Art of Readable Code
This is probably a stylistic thing but the Art of Readable Code is a very light read about a very heavy topic. It is amazing that they were able to do that. Despite being only a couple of hundred pages it delivers clear advice and gives example of both good and bad style. While Clean Code gets deeper in the weeds and talks about more than just readable code. It is a worthwhile read on its own. This book is definitely a great book to introduce you to the topic. Most IT books are all heavy on the topic and light on the fun. These guys speed along with plenty of little comic strips that support the lesson they are trying to teach. They don’t dig too deep so things move along fast. It is very much do this and here is why. It was an enjoyable read.
I don’t have much to say about this that is bad. It is a very good book that focuses on style concerns. It gives solid advice and does not judge you for your chosen style. They just want you to communicate better. For the “independently” minded individuals that are waiting for someone to tell them what to think, this book is probably frustrating. I almost made an iDrone comment here. Thank God I stopped myself. DOH.
They advocate doing things that maybe counter to their advice, if it is how the shop operates. Bringing in a new style could cause chaos in such an environment. That pragmatic focus on maximum readability to the audience you are coding for can come across as a bit spineless.
Personally, I generally try to do that, though I will start adapting things to my style once they become my responsibility. That is the positive of being in a shop of one. While under the tyranny of working in a government workshop, I obeyed, 1984 style. If I violated it, I commented the hell out of what I did and why so as to prevent confusion. I can’t say what it is like in a massive corporation since my experience does not count. I was telling them what to do.
The Verdict on Art of Readable Code?
I really loves the Art of Readable Code. If I was working with a junior developer, once we got past the basics of coding, like looping, conditionals, functions, classes and what not, I would hand them this book. I would do it before giving them Clean Code. As with Clean Code, this should be a staple of every developers library. Do it before Clean Code to get the most positive gain.