When you are a new developer, you’re always listening for the “rules.” In Ruby, we have little things that most people agree on, such as indentations and spaces around brackets, despite the fact that Ruby doesn’t care at all about spaces. I happen to love rules, and I used to blindly accept them. Now, at least I do a little research before giving in.
I’d like to talk about implicit vs explicit returns. They are SO controversial. Apparently.
While learning Ruby, I was taught that using an explicit return is not such a bad thing. But I never learned why. I would find myself using one at the end of a method, to keep some lonely local variable company, such as
return item, but I didn’t know why. I found myself using it in the beginning or middle of a block, but I didn’t think to not use it, and now I am wondering why. So, here is the newish Ruby developer’s guide to using, or not using, explicit returns.
I have a writing background, so I appreciate the opportunity to write code that reads easily. In fact, I don’t think I ever would have gotten as far as I am today without this happy Ruby trait, and I know I am not the only one. Ruby’s readability is a huge draw, and is an attribute very much worth defending. So, when an opportunity comes to be explicit and clear when you feel it adds to the readability of the code, you can see why so many people come to the side of including an explicit return here and there.
What would be the counter-argument here? Probably knowledge of your tools. As a Ruby developer, you should know that Ruby always returns the last evaluated statement, whether you said so or not. Which leads to the next heading…
Another huge draw to Ruby is more immediately obvious to seasoned developers who have spent too much time wading through lines and lines and lines and lines of code until they get to the end of what they were doing and couldn’t remember what they were doing. Ruby isn’t like that. Ruby. Likes. It. Short. We all have to admit how satisfying it is to take a multiline method down to one line. Or how about those pull requests where you remove more lines of code than you add? Bliss.
So the argument here is to get rid of those returns! They aren’t needed and I have character constraint issues!
But conciseness sometimes steals from readability, and can tuck away intentions or side effects that aren’t apparent upon first (or second, or third) glance. Is this going to be the case with an implicit return? It can be. Here is the famous example, where it would be unclear whether a return value was meant or not. Explicitly returning nil might make you cringe, but it would make the intent obvious.
The Community Consensus
Back in 2011, in an early PR against the Ruby Style Guide, Bozhidar Batsov said he would never change the “Avoid return where not required” portion of the guide. The PR asked to require it, to help differentiate between methods that arrive at a return value, or methods that call other methods.
Then in 2013, he considered amending the rule, but only in the case where a method has multiple exits and the returns are needed. He closed the PR, but eventually the rule was updated to read “Avoid return where not required for flow control.” Subtle, huh.
Airbnb still maintains “Avoid return where not required” in their style guide, but went through a lengthy discussion about whether to possibly, maybe, not sure, but should always recommend using it always (the waffling tone was probably the biggest downfall). No one could agree on an absolute rule for when an explicit return would generally be recommended. I read a lot of “Thanks for your suggestion. I disagree,” comments. Bottom line…the Ruby community does not prefer it.
When I started looking into this, I believed the rule was to never use explicit returns ever. Now I see that they are still necessary in certain cases, and when you see them, it’s more a flag to pay attention to all the things the method is doing. I have noticed lately that I can put in a little more effort to get rid of my explicit returns, sometimes even the early ones.
Many happy returns to you…or not!