Home > programming > Abstraction is The Name of The Game

Abstraction is The Name of The Game

October 30th, 2007

I just read a post by Uncle Bob that discusses the optimal length of a function. He quite correctly claims that the old functions-should-fit-on-a-screen rule lost its validity. He further states that “A well written function might be 4, 5, perhaps 8 lines long; but no longer.”

I’m not saying Uncle Bob is wrong, most well written functions are indeed short, but specific guidelines like that always makes me hesitant. The problem I see is that these rules tend to become an end in themselves, while the real purpose – the reason that the rule was once formulated – end up in the background.

I mean, you shouldn’t make a function short for the sake of making it short. A short function is not necessarily well-written, and a well-written function is not necessarily short. So, what makes a function well-written? Well, here’s my definition:

A piece of code is well-written if you with little effort can figure out what it does.

Keeping a function short certainly helps, but what really matters is how well it reflects intention and how well it hides details. So, don’t think lines of code, think abstraction.


Be Sociable, Share!
Categories: programming Tags:
  1. October 31st, 2007 at 18:01 | #1

    I agree with your premise. But inevitably you’ll need to fall back onto more concrete metrics in order to make any kind of objective judgment. Your definition is just too subjective.

    You – Who is you? Are you you? Are you you at 3am in the morning? Are you you 6 months from now? Are you you when you’ve moved on to another position, and a new you is supporting the code?

    Little Effort – How much is a little effort? Ten minutes? Twenty minutes, but I get to listen to whatever I want on my ipod? Thirty minutes but I don’t have the internet to look up any obscure library members?

    I don’t know what numbers I’d use for these, but here are the things which I think you’d want to attach metrics to:
    – lines of code
    – levels of indention
    – number of local variables
    – depth of member referencing (ie. foo.bar = 1, foo.bar.baz = 2, foo.bar.baz.foo = 3)
    – number of nested parenthesis on a single line

    • November 1st, 2007 at 13:01 | #2

      You raise a valid point, and if the goal is to do some kind of automatic analysis we have to use concrete metrics. But, how do you put metrics on how well-named a function is, how well-abstracted a piece of code is, or how well it reflects intention?

      Also, I like the subjective nature of my definition. With it I’m free to put my own standard. Here’s mine:

      “You”: it’s me or someone like me, (at least) six months from now.
      “Little Effort”: if it *feels* simple, it’s also “little effort”.

      With that said, I too try to keep functions short and with few levels of indentations, but that comes naturally since I focus on abstraction.

  2. November 1st, 2007 at 14:11 | #3

    Great blog! While my first reaction to Uncle Bob’s post was to share your concern, I’ve convinced myself not to worry about it too much with the following train of thought:

    Even though Uncle Bob uses the word “rules”, I think he really means “guidelines”. In other words, their value comes not from following them dogmatically, but from prompting you to think twice about what you’re doing when you break one.

    Such guidelines allow us to produce good code without the mental paralysis that can result from second-guessing ourselves all the time. This is especially useful for inexperienced developers.

    The only downside occurs if someone who otherwise might develop their own more sophisticated heuristics decided to follow such a set of guidelines dogmatically instead. I don’t think this will happen. Smart developers will always use any guideline they read as a starting point for develop their own more sophisticated heuristics. For those that are naturally inclined to follow dogma, the best you can do is give them slightly more useful dogma.


    P.S. Perhaps “A piece of code is well-written if the guy in the next cubicle with little effort can figure out what it does.” would be more useful in convincing folks to change their ways? After all, the code I’ve written is always easy for me to understand. 😉

    • November 2nd, 2007 at 08:06 | #4

      Thanks for your comment. I too think he meant it like a guideline, although it looks like a rule.
      And, I like the “the guy in the next cubicle” change. I think I’ll go with that. 🙂

  3. Dave G
    November 2nd, 2007 at 02:55 | #5

    First of all, Uncle Bob’s statement was clearly a rule, not a guideline, stating that any function longer than 8 lines cannot be considered well-written. He stated it quite unequivocally. The words “but no longer” leave no room for interpretation.

    The guy’s a drooling moron.

    He’s one of those guys who has been pontificating for so long that he seems to think that he can make things true simply by saying them. “I think, therefore I am correct.” When he needs to fill space on his blog, he comes up with garbage like that statement, and the other stupid rules he wrote in that post.

    But, he’s been around a long time, has written some worthwhile stuff in the past, and a lot of people respect him, so he gets a pass for this crap. Note the way you (Hans) and some of the other commenters tiptoe around it. You’re “not saying Uncle Bob is wrong” (but he clearly is) but you’re “hesitant.”

    If no one else will say it, I will. Uncle Bob is an emperor with no clothes.

    • November 2nd, 2007 at 08:21 | #6

      Thank you for your comment.
      I like it when people are straight-forward, but I strongly disagree with you on this one. I’d never call Uncle Bob (or anyone else for that matter) a moron.

Comments are closed.