Clean Code: Intro, Clean Code and Meaningful Names (up to the end of chapter 2)

[Nate Finch]

Sorry, I've had this half typed out for like a week and a half.

A general overview - I was actually really excited about the book. I try to
stress in words and actions that readable code is so much more important
than almost anything else. However, I find that the author's definition and
mine diverge somewhat. I was also really unhappy that he focuses so closely
on java without even an attempt to make his statements apply to multiple
languages. Obviously, we can still do the translation ourselves, but it
seems like he should have just called it "Clean Java Code"

I don't think I really disagree with most of what he says in chapter 2. I
think my min and max tolerances for length of variable names is just on the
lower end of the spectrum than the author's.  I think the later chapters
are a lot more interesting :)

People complain about single letter variable names, but if the function is
only 10 lines long, does it really matter? You can see s := thing.State()
 ... so you know it's a state.  Does it make it clearer to call it state
when you see it used 2 lines below?  I don't think so.  That being said,
it's fine to call it state, too.  It's just when you call it
thingStateForReviewLater that it actually makes the code harder to read
when it's used in more than trivial expressions.

One of the things I like a lot is the idea of using the context of how a
function will be called to avoid extraneous words in the function name.
 This works especially well in Go, since you call functions prepended by
the name of the package, so like container.Insert(ball), instead of
container.InsertBallIntoContainer(ball).

-Nate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20130926/a64f8a89/attachment.html>