Closed olleolleolle closed 4 years ago
I like this, but I'm also on the fence. What's your internal model for implicit returns?
For me, I see implicit returns as part of a functional style. As soon as I feel there is any ambiguity as to what is going on, I try to use explicit returns. The reason for that is because I've seen implicit returns cause bugs, especially as ruby is dynamically typed and the interpreter can't generally warn you if something implicit becomes part of the public interface (or something that was implicit is no longer, due to changes in flow control).
Welcome any thoughts.
The model for me would be: everything has a return value and if I want it to be nil in some cases ("oh the exception I handled by logging it returns the Logger instance instead of acting like puts which returns nil") I need to make it nil there.
In YARD, there's a return type called void, which is used to communicate to a reader that whatever is returned here is... To be unused. I find that a TODO in the implementation, I'd want people implementing to decide if that actually returns anything.
Thanks for asking, I perhaps had a folk model of this, and it helped me to express it.
This PR updates examples to avoid a -W2 warnings (about an unused variable).