On 10/26/06, Pete Y. [email protected] wrote:
return truedef odd? self % 2 == 1 end def even? self % 2 == 0 endend
class Fixnum
def even?
(self % 2).zero?
end
def odd?
!even?
end
end
Robert O. wrote:
I normally do that, but I remember somewhere reading that it was bad
form to
not include the return statement. I’m not sure where this was. Is anyone
familiar with this syntax quasi-rule?
I tend to use un-necessary “return” statements in most of my code,
because it makes it easier for me to read. But I suppose the language
designers that provide simplified syntax do so for a reason, so I would
say the correct style is the minimum amount of code the language allows.
M. Edward (Ed) Borasky wrote:
Not including a “return” statement makes it all a bit more “functional”
in my view. Basically, I’ll leave off the return if the method is
really simple and it’s obvious what the last statement is and that it’s
being returned. If there’s any complex control flow going on then it’s
nicer to give the “reader”(potentially just yourself, but being nice to
your future self is good) the visual clue as to what’s actually being
returned, even if it’s still the last statement executed.
On 10/26/06, Wilson B. [email protected] wrote:
I normally do that, but I remember somewhere reading that it was bad
form to
not include the return statement. I’m not sure where this was. Is
anyone
familiar with this syntax quasi-rule?
–
Robert W. Oliver II
President, OCS Solutions, Inc. - Web Hosting and Development
Toll-Free Phone - 1-800-672-8415
OCS Ruby Forums - http://www.rubyforums.com/
My Blog - http://www.rwoliver.com/
On 10/27/06, John T. [email protected] wrote:
Not including a “return” statement makes it all a bit more “functional”
in my view. Basically, I’ll leave off the return if the method is
really simple and it’s obvious what the last statement is and that it’s
being returned. If there’s any complex control flow going on then it’s
nicer to give the “reader”(potentially just yourself, but being nice to
your future self is good) the visual clue as to what’s actually being
returned, even if it’s still the last statement executed.
I thought about leaving the return off, as self % 2 would return a 0 or
1,
and 0 or 1 does not mean true or false. But then again, as someone
pointed
out previously, the method to check for zero is best there, and that
does
return true or nil. That was the best approach I suppose.
Then again tho, the return statements will lead to more readability for
programmers who don’t know Ruby.
–
Robert W. Oliver II
President, OCS Solutions, Inc. - Web Hosting and Development
Toll-Free Phone - 1-800-672-8415
OCS Ruby Forums - http://www.rubyforums.com/
My Blog - http://www.rwoliver.com/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Robert O. wrote:
| On 10/26/06, Wilson B. [email protected] wrote:
|>
|> class Fixnum
|> def even?
|> (self % 2).zero?
|> end
|> def odd?
|> !even?
|> end
|> end
|>
|>
| I normally do that, but I remember somewhere reading that it was
| bad form to not include the return statement. I’m not sure where
| this was. Is anyone familiar with this syntax quasi-rule?
It is a programming-paradigm-dependent semantics rule. If one follows
the functional paradigm, one would write leap? in this way:
class Fixnum
~ def leap?
~ if (self % 400).zero?
~ true
~ elsif (self % 100).zero?
~ false
~ elsif (self % 4).zero?
~ true
~ else
~ false
~ end
~ end
end
if one follows the proceural paradigm one would rather write
class Fixnum
~ def leap?
~ if (self % 400).zero?
~ return true
~ elsif (self % 100).zero?
~ return false
~ elsif (self % 4).zero?
~ return true
~ else
~ return false
~ end
~ end
end
Bad style came into play if one would write something like
class Fixnum
~ def leap?
~ if (self % 400).zero?
~ return true
~ elsif (self % 100).zero?
~ return false
~ elsif (self % 4).zero?
~ return true
~ end
~ false
~ end
end
because in this case one starts with the procedural paradigm and
switches to the functional paradigm. An example of bad style were:
class Fixnum
~ def leap?
~ return true if (self % 400).zero?
~ return false if (self % 100).zero?
~ return true if (self % 4).zero?
~ false
~ end
end
While not being necessary it improves code to add a return in order
to stick to the procedural paradigm.
class Fixnum
~ def leap?
~ return true if (self % 400).zero?
~ return false if (self % 100).zero?
~ return true if (self % 4).zero?
~ return false
~ end
end
Some rules of thumb:
~ - Use or avoid return consistently.
~ - Make your code reflect your intention to the maximum extend
~ permited by the language you use - if you want a procedure to
~ return some value use “return”, if you want a function to evaluate
~ to some value don’t.
HTH,
Jupp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFQnB6rhv7B2zGV08RAoiyAJ9dbts+7x2jfwjNWGYuoQiWhO7bUwCg3b4D
H5CZe2xIBqcXalxCX1br7Xg=
=jdH6
-----END PGP SIGNATURE-----
On Fri, 27 Oct 2006, Robert O. wrote:
Then again tho, the return statements will lead to more readability for
programmers who don’t know Ruby.
i always consider that i’m doing programmers who don’t know ruby a
favour by
using idiomatic ruby - it minimizes the amount of time they require to
come up
to speed and provides better context for them to ask questions to people
like
this list, who are also used to reading idiomatic ruby.
2 cts.
-a