4 ms·

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 nest

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.

ryanbrunner 6y ago
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.)

ryanbrunner 6y ago

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