The PHP community has morphed “Avoid else” into “Never use else”. The idea was originally taken from Code calisthenics for Java, adapted for PHP and popularized by varios conference talks.
The benefits of early return are obvious, but to avoid using “else” altogether is just silly and can lead to some convoluted code.
Ruby community is also obsessed with enforcing small-scale coding rules (this is aspect I dislike most in ruby’s culture). For example, default settings of rubocop, the most popular ruby linter, forbids something like this:
def check_thermal_safety
if widgets_temperature > 100
stop_warp_engine
end
end
It forces user to invert logic like this:
def check_thermal_safety
return unless widgets_temperature > 100
stop_warp_engine
end
Primary reason for applying guides without questioning might be that lots of projects run linters on CI. Your code will not pass if you don’t obey style guide.
Disabling checks for blocks of code are not very convenient in most linters. For example rubocop allows to disable check before block and to enable after it. I’m not even sure if rubocop:enable all will not turn all checks after this block, even if only few checks are enabled in config. And nowadays any comments are red rag for code reviewers because “comments are code smell”.
I think this style is acceptable for things like raise where it’s obvious at a glance that you would never do it unconditionally, but for anything more subtle it’s a readability disaster.
This style is not that bad, but only if text editor is configured to show keywords such as if in color/font that stands out. It’s almost unreadable without syntax highlighting.
Rubocop does not issue warning for this style. But this option of formating is available only if condition expression and body are small. This is the case when style guide requires you to rewrite code (negate logic, add return) if expression becomes larger (for example, if method is renamed).
The PHP community has morphed “Avoid else” into “Never use else”. The idea was originally taken from Code calisthenics for Java, adapted for PHP and popularized by varios conference talks.
The benefits of early return are obvious, but to avoid using “else” altogether is just silly and can lead to some convoluted code.
Ruby community is also obsessed with enforcing small-scale coding rules (this is aspect I dislike most in ruby’s culture). For example, default settings of rubocop, the most popular ruby linter, forbids something like this:
It forces user to invert logic like this:
I find this less readable, and moreover, it’s defined in style guide that almost became analogue of python’s pep-8 and it’s enforced by “canonical” ruby linter with default settings.
However, avoiding long nesting, like in this article, is ok, I think.
The thing I like, but many ignore, about PEP-8 is that it encourages breaking the rules when it makes sense to do so: A Foolish Consistency is the Hobgoblin of Little Minds.
And Beyond PEP-8 is a good talk about how people tend to miss the point of style guides.
Primary reason for applying guides without questioning might be that lots of projects run linters on CI. Your code will not pass if you don’t obey style guide.
Disabling checks for blocks of code are not very convenient in most linters. For example rubocop allows to disable check before block and to enable after it. I’m not even sure if
rubocop:enable allwill not turn all checks after this block, even if only few checks are enabled in config. And nowadays any comments are red rag for code reviewers because “comments are code smell”.I’ve also seen this style, which in certain cases hides the conditional:
I think this style is acceptable for things like
raisewhere it’s obvious at a glance that you would never do it unconditionally, but for anything more subtle it’s a readability disaster.This style is not that bad, but only if text editor is configured to show keywords such as
ifin color/font that stands out. It’s almost unreadable without syntax highlighting.Rubocop does not issue warning for this style. But this option of formating is available only if condition expression and body are small. This is the case when style guide requires you to rewrite code (negate logic, add return) if expression becomes larger (for example, if method is renamed).
For what it’s worth, as a full-time ruby dev for 6 or 7 years now, this is my take on the “ruby idiomatic” way of writing this method.