About the code samples for "Avoid use of nested conditionals for flow of control"

Regarding the rules about using nested conditionals for flow of control found here, I wanted to raise attention to these two particular fragments of the bad vs good code samples:

# (supposedly) bad
if thing[:foo][:bar]
  partial_compute(thing)
else
  re_compute(thing)
end

# (supposedly) good
return re_compute(thing) unless thing[:foo][:bar]
partial_compute(thing)

I agree with the overall rule, but I would argue that looking at these two fragments as variants on their own, the first one above is more acceptable than the second one. At least I have to think more with the second one to understand what's going on, than with the first one.

Plus, making the change from the first one to the second, when you see the complete code samples in the aforementioned rule, has nothing to do with what the rule states, which is:

A guard clause is a conditional statement at the top of a function that bails out as soon as it can.

This part of the original function in the "bad" sample is not at the top of the function, so it shouldn't require to be changed.

Additionally, in the full code sample, after converting the top-level conditional into a guard statement, this other if/else conditional is no longer nested, so the rule does not apply to it anyway, given the title of the rule is

Avoid use of nested conditionals for flow of control

Start with the linked “Avoid use of nested conditionals for flow of control” section and compare its stated rule with the two Ruby examples and the full code sample quoted here. Determine whether the examples and explanation consistently demonstrate the rule; done means the section no longer implies a change outside that rule’s scope.