2.3 KiB
+++ title = "Clean Code: A Handbook of Agile Software Craftsmanship - Robert C. Martin" date = 2015-01-25
[taxonomies] tags = ["books", "robert c. martin", "it", "reviews", "3 stars"] +++
GoodReads Summary: 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.
{{ stars(stars=3) }}
About the edition
If there is one single weird thing about the Kindle edition is the code formatting. While reading code in non-monospaced font is weird but not impossible, reading code in non-monospaced font that is justified like normal text is.
The really annoying part is that, at the end of the book, the full listing of the discussed code is shown as "images", large blocks of code that don't follow the selected Kindle background and doesn't seem to allow selection, but it is monospaced and it is not justified. Why won't they use it all over the code is beyond me.
About the content
The book goes with a good start, listing almost all the pet peeves I have with other people code ("why the fuck they named things like this?", "why the hell this function have that many parameters?" and so on -- heck, even the problem with consistent style was there). Although it points the problem and how to improved it, it sometimes lacks the why those changes need to be made.
But, then, things start to really go downhill, with lots of stuff that contradicts previous statements (specially the Single Responsibility Principle), and a bunch of things that are language specific. There is one really good chapter that picks a code and goes slowly showing the principles discussed in the start of the book, applying one after the other, so you can see the code changing and becoming easier to read. The sad part is that it is used only once.
Honestly, I which there was a lot more of "why you should do this", only because as a seasoned programmer, I agree -- and use -- with a lot of the points in the book, but I lack the experience the tell younger programmers why they should not do what they are doing.
It's a good book, nonetheless, although not exceptionally good.