Hacker News Reader

Comment by WesolyKubeczek | Hacker News Reader

For me, guard clauses look more readable, especially that they can be easily added or eliminated, they separate main logic from edge cases, and they reduce nested clauses a lot. Stomping a foot about "branching must look like branching at all cost" reeks more of a religion than anything else.

Or maybe, if the author has a custom style, they should make their own linter rules.

Or maybe, just maybe, be hardcore and don't use linters at all. If you treat your code style as a form of art unto itself (which is not a bad thing at all IMO, depending on what you create), linters can be detrimental — they sure strip your code of a lot of its character.

View on HN

I don't think it's a case of guard clauses being more or less readable in and of themselves. The point the authour is trying to make is that guard clauses convey a different intent from a standard branch. It's a way of communicating "this method is not relevant / necessary (or sometimes invalid if you're raising) for this set of inputs". If what the guard clause is doing is the "point" of your method, you're losing that intent from someone reading it, and conveying something else.

I don't think it's Rubocop's fault in this case - there's really no way that we can expect a linter to glean "what is this method really about". But structural issues like this probably don't make sense to use a linter for IMO.

In his case, the guard clause is completely appropriate, because "super" is "the rest of the method" the guard clause is protecting. It's not a filter method, it's a selective render method.

Sure, I can see that argument. But the larger point is that that can't be universally applied to every case that Rubocop flags.

Then the author should have made their case with a more suitable example. I bet they could have found cases with something that's absolutely not a guard clause in a disguise getting converted into a guard clause proper.

Unless they couldn't, and the linter does a good job. ;-)

I literally hit two today. Off the top of my head:

    def enhance_payload(payload)
      payload[:h] = thing_h

      if situation_one?
        payload[:a] = thing_a
        payload[:b] = thing_b
      end

      if situation_two?
        payload[:x] = thing_x
        payload[:y] = thing_y
      end
    end

Which RuboCop suggests to turn into:

    def enhance_payload(payload)
      payload[:h] = thing_h

      if situation_one?
        payload[:a] = thing_a
        payload[:b] = thing_b
      end

      return unless situation_two?

      payload[:x] = thing_x
      payload[:y] = thing_y
    end

But if you move the first line of the method down to the be the last line, suddenly it's not important to use a guard clause anymore.

If you can't think of examples, then you haven't been doing much thinking.

> The point the authour is trying to make is that guard clauses convey a different intent from a standard branch.

This is a matter of idiom and convention, and I disagree with the author on the specific point in Ruby. Were it Python, I would agree with it. (Well, not on "guard clauses" per se, but the significance of an implicit vs. explicit nil/None return.)

It is certainly an issue for polyglot programmers that as well as differences in syntax and behaviorally-visible semantics, language communities have different idioms that impact the communicative semantics of code (having been deeper into Ruby before getting more into Python, it took my a while to stop writing Python with Ruby conventions.)

Reply on news.ycombinator.com