Hacker News Reader

Comment by joe_the_user | Hacker News Reader

I find that

    display_warning() if problem_condition()

feels much more expressive in some situations than

    if(problem_condition) display_warning()

The later just emphasizes the primary activity to me - again, in some circumstances. It's something I miss now that I'm not doing Ruby anymore.

View on HN

That breaks efficient code reading. When you read code, you tend to skip through basic-blocks (i.e. consecutive statements without branches) and follow them to that intersection point where a decision has to be made. In traditional form, if you have:

  if (condition) consequence();

You're able to "run" the condition in your head and step into the consequence without loss of pace. But when you put the consequence before the condition, you will have to backtrack.

unless the consequence itself is something that signifies the end of a basic block, like a break or a next or a return.

  backtrack = true unless consequence.signifies? :block_end

It doesn't seem that much harder to read.

Unfortunately though you are potentially adding subtle bugs here which can only be caught at run time.

To avoid excessive test coverage it would be more pragmatic to do:

  backtrack = (consequence.signifies? :block_end) ? false : true

But that's not as easy to read :(

I didn't reply to that one-liner because it is a one-liner.

A lot of software engineering lore crumbles into tautologies or is completely obviated when you're working at the microscopic level.

Reply on news.ycombinator.com