Writing clean code
Robert C. Martin was at it again with another excellent book for programmers (professional or hobbyists). Clean code is a book for programmers who want to strive towards writing more readable and maintanable code. That much you may have surmised. It's important to note that while the book offers plenty of suggestions for areas on ways code could be improved, more value can be extracted out of it if you walk away knowing the fundamentals of clean code and figuring out how best to apply it to your code.
Coming from university, for the most part, we were not assessed on code style. The main thing was to get the code to work. And then we left it there and started working on the next assignment. In only one module did we write an extensive set of tests. Even then, the code was filled with smells galore. If we weren't assessed on code style, why bother spending the time (which was of short supply) and effort in the first place? The issue with this mentality is that this could also be said for the workplace. If your company just wants you to churn out as much (short-lasting) "business value" as possible, you may feel inclined to forego thinking about future maintainers or even the rest of your team. Now, that's not true of all companies. Some may actually value clean code. Others may pay lip service to it by enthusiastically supporting it on the one hand but lamenting a team's velocity on the other. Unit tests? We'll get to that later (does later actually happen?). OK, OK. You get the point.
Having read the book, I find that the code I write (or strive to write) is significantly cleaner. Things like checking for test code coverage and splitting classes into lots of smaller ones are now routine. On that last point, I was often skeptical of splitting a class into too many smaller classes. It seemed unecessary. There's certainly a line to be drawn here, but Martin swayed my mind on this by asking the reader, by way of analogy, whether they would prefer to have everything in one box or small quantities in several (where it's more organised and easier to find).
The spiel about my university experience was also meant to highlight who I think this book is for. In general, I would recommend it for new developers, junior or self-taught. My expectation is that more senior developers would know a lot of the things mentioned in the book, but it may still be quite useful to go through, regardless. Martin looked at snippets of well-written code from various codebases including JUnit. If Martin could find ways to critique and improve well-known existing libraries, you may find something valuable yourself.
