When Code Climate and Tammer Saleh from Thunderbolt Labs teamed up to offer free code reviews at RubyConf, I seized the opportunity to get feedback on my first Ruby gem – gnip-rule). A number of refactorings came out of that session, but one I found most interesting was an approach to making conditionals more maintainable in languages like Ruby and CoffeeScript.
They say that the use of conditionals in Ruby is a code smell. Decisions about how your team approaches conditionals should be discussed then outlined in your project styleguide.
This is the refactoring I’m talking about – I have a bunch of different checks according to Gnip’s PowerTrack API constraints to ensure that a PowerTrack rule follows the constraints.
1 2 3 4 5 6 7 8 9 10 11 12 13
…And here is the same method, refactored. We turned each condition into an early
return if the conditional expression is true:
1 2 3 4 5 6 7 8 9 10 11 12
Some might cringe at seeing so many
return statements, but I argue that it’s more maintainable this way because it’s
obvious to the reader what is being checked. If another check is added, it doesn’t hang off a long chain of
use a bunch of ugly
\s to break lines).
Not only is this useful in Ruby, but CoffeeScript as well. Example:
1 2 3 4 5 6
Thank you again, Tammer, for your very helpful advice.
What do you think of this formatting?