|
|
|
|
+++
|
|
|
|
|
title = "Clean Code: A Handbook of Agile Software Craftsmanship - Robert C. Martin"
|
|
|
|
|
date = 2015-01-25
|
|
|
|
|
|
|
|
|
|
[taxonomies]
|
|
|
|
|
tags = ["books", "robert c. martin", "it", "reviews"]
|
|
|
|
|
+++
|
|
|
|
|
|
|
|
|
|
[GoodReads Summary](https://www.goodreads.com/book/show/3735293-clean-code):
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
<!-- more -->
|
|
|
|
|
|
|
|
|
|
{{ 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.
|
