The source content for blog.juliobiason.me
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

55 lines
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](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.