3 ms·

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 conve

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.

arto64 6y ago
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.
- ryanbrunner 6y ago
  Sure, I can see that argument. But the larger point is that that can't be universally applied to every case that Rubocop flags.
  - WesolyKubeczek 6y ago
    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. ;-)
    - boyakasha 6y ago
      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.
dragonwriter 6y ago
> 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.)

arto64 6y ago

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.

ryanbrunner 6y ago
Sure, I can see that argument. But the larger point is that that can't be universally applied to every case that Rubocop flags.
- WesolyKubeczek 6y ago
  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. ;-)
  - boyakasha 6y ago
    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.

dragonwriter 6y ago

> 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.)