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
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
