The de-facto community style guide for Ruby suggests using parens if the method accepts paramters and leaving off the parens if the method takes no parameters.
both are equivalent because (roughly) x != None <=> x != False <=> x == True <=> bool(x) so if one applies ("bool"), != None has to be considered the same here.
Again, the recommandation is here to avoid, imo, that beginners fall in the trap I mentionned above. I don't say there are no other reasons, tho. Just that I don't see them right now.
Sticking to conventions is good but you need to understand the reasons for them. That convention is meaningful only when you can have some ambiguity between None and other "falsy" values. Like:
But considere the current case: you receive either None or an object whose boolean equivalent won't be "falsy" (even if it "holds" an empty string). So there is no ambiguity there, so you can work with either method/approach you want, that won't change a thing.
Style guides are just conventions. Use them wisely, not blindly. ;)
(note: about best practices, what is that ^ doing in there??? ;p )
This comment is hidden because it contains spoiler information about the solution
spoiler flag...
The de-facto community style guide for Ruby suggests using parens if the method accepts paramters and leaving off the parens if the method takes no parameters.
both are equivalent because (roughly)
x != None<=>x != False<=>x == True<=>bool(x)so if one applies ("bool"),!= Nonehas to be considered the same here.Again, the recommandation is here to avoid, imo, that beginners fall in the trap I mentionned above. I don't say there are no other reasons, tho. Just that I don't see them right now.
Sticking to conventions is good but you need to understand the reasons for them. That convention is meaningful only when you can have some ambiguity between
Noneand other "falsy" values. Like:But considere the current case: you receive either
Noneor an object whose boolean equivalent won't be "falsy" (even if it "holds" an empty string). So there is no ambiguity there, so you can work with either method/approach you want, that won't change a thing.Style guides are just conventions. Use them wisely, not blindly. ;)
(note: about best practices, what is that
^doing in there??? ;p )