I really would be interested in your thoughts about this
a. in the context of your own projects, and
b. with regard to teaching programming newbies
The GitHub Ruby Styleguide [1] states: “The and and or keywords are
banned. It’s just not worth it. Always use && and || instead”.
So what’s your practice/recommendation:
use only &&, ||
use only and', or’
distinguish between boolean expressions (if this && that)
and control flow (loot = give_money or die)
???
and 2. might require extra parentheses that often could be
avoided with 3., but using parentheses might be clearer anyway.
Especially for students who might have a hard time coping with
the different precedences.
I want to use a consistent style so I don’t have to think about the
precedences that much. This and the fact that I more frequently use &&
and || brings me to the conclusion that 1. is just more useful, because
I have to write less parentheses which in turn make the code easier to
read (at least imo). This also makes it easier to learn Ruby/programming
for newbies.
Compare:
foo = hsh[:bar] || hsh[:alternative] || “” # I think lines like these
are quite common, because many libraries like to use hashes as
parameters and initialization like this is very expressive
to
foo = ( hsh[:bar] or hsh[:alternative] or “” ) # I think the
additional parentheses just distract from what I want to accomplish,
which is just an initialization. Parentheses to me always smell like
complex computation (which this is not)
In my opinion using || in this case is more clear, because you can read
the || as “or”.
And one thing I want to add to your third proposed practice: In the case
of “loot = give_money or die” I’d almost certainly think that the or is
evaluated before the assignment (just because of the different
precedences) at first.
Well, you might already be familiar with this, but this is what I use:
“Use &&/|| for boolean expressions, and/or for control flow. (Rule of
thumb: If you have to use outer parentheses, you are using the wrong
operators.)”
Well, you might already be familiar with this, but this is what I use:
“Use &&/|| for boolean expressions, and/or for control flow. (Rule of
thumb: If you have to use outer parentheses, you are using the wrong
operators.)”
The GitHub Ruby Styleguide [1] states: “The and and or keywords are banned.
It’s just not worth it. Always use && and || instead”.
That’s what I do. You’ve already been quoted the Ruby Style Guide, so
that leaves using the verbal versions for control flow. I’ve tried to
get used to that, and frankly it just doesn’t seem anywhere near as
clear as “if this_fails do_that”. Using and/or for control flow is a
popular idiom in Perl, but that doesn’t say anything about its clarity
(at least, anything positive), which is very important to Rubyists.
Well, you might already be familiar with this, but this is what I use:
“Use &&/|| for boolean expressions, and/or for control flow. (Rule of
thumb: If you have to use outer parentheses, you are using the wrong
operators.)”
This can help you: Learn How to Blog and Build Websites for Profit!
It’s the ruby operators by relevance, very usefull for beginners to
understand how to work without parentheses(although not recommended).
And also to know which or not is a method. See you around.
I do understand their different precedence, that was not the point
at all. But thanks anyway.
This can help you: Learn How to Blog and Build Websites for Profit!
It’s the ruby operators by relevance, very usefull for beginners to
understand how to work without parentheses(although not recommended).
And also to know which or not is a method. See you around.
I use and/or for logical expressions and &&/|| for technical stuff like
default values. I never use any of them for control flow, because that’s
just too much magic. Especially since if/unless modifiers are just as
compact and much clearer.
Personally, I hate &&/|| in “if” statements. This is not C or Java! We
have actual English words for that, not those ugly leftovers from
ancient times where people thought bit operators were more important
then logical expressions.
And how is the low precendence of and/or “dangerous”? Isn’t that exactly
what you want in an “if” statement? To have the logical operators
evaluated at the very end?
And how is the low precendence of and/or “dangerous”? Isn’t that
exactly what you want in an “if” statement? To have the logical
operators executed at the very end?
No! No! 1000.times :no!
Consider the difference between “x = true && false” and “x = true and
false”. Since && has HIGHER precedence than =, “x = true && false” is
equivalent to “x = (true && false)”, just as you might expect. The
whole expression (including the assignment) evaluates to false, and x
is assigned false. No problem. But since “and” has LOWER precedence
than =, “x = true and false” is equivalent to “(x = true) and false”.
You smell something wrong already, don’t you? The whole expression
(including assignment) evaluates to false again… but lo and behold,
x is true! That’s because you’ve left the boolean operators wait
until the end, as you believe might be so harmless.
The analogous situation for || versus “or” is left as an exercise for
the reader.
BTW, these two were already part of a talk I’ve been working on, on
Ruby Gotchas, coming soon to a RUG near you. Well, at least near me.
The GitHub Ruby Styleguide [1] states: “The and and or keywords are banned.
It’s just not worth it. Always use && and || instead”.
That’s what I do. You’ve already been quoted the Ruby Style Guide, so
that leaves using the verbal versions for control flow. I’ve tried to
get used to that, and frankly it just doesn’t seem anywhere near as
clear as “if this_fails do_that”. Using and/or for control flow is a
popular idiom in Perl, but that doesn’t say anything about its clarity
(at least, anything positive), which is very important to Rubyists.
-Dave
There’s only one time I can think of where I use “or” for the sake of
readability. I’ll often have a main method call a series of other
methods, each of which returns a boolean, and sets the error level as a
way of reporting failure. That is then passed to the errorhandler. This
leads to some simple lines like this:
Consider the difference between “x = true && false” and “x = true and
false”. Since && has HIGHER precedence than =, “x = true && false” is
equivalent to “x = (true && false)”, just as you might expect.
Why would I expect that? Why would I even use assignments in “if”
statements?
I think Dave was not talking about an assignment in an if statement,
just a “pure” assignment of a boolean expression to a variable.
[…]
Maybe my programming style is totally out of fashion, but my “if”
statements usually look like this:
if and ( or )
…
end
[…]
When I want to do “magic” like
var = val || alt
then I do use &&/||. But this is a very different context.
What I do not like about this approach is that the used operators
depend on the context (condition in if statement / condition assigned
to a variable), not on the purpose (condition vs. control flow).
Every time you want to refactor an if statement by pulling out the
condition into a variable you have to change operators:
if condition_one and condition_two
…
end
becomes
valid = condition_one && condition_two
if valid
…
end
Sorry, but if you use assignments in “if” statements (much too obscure)
then I do use &&/||. But this is a very different context.
I totally agree with Jan E.
What reason is there for Ruby to have “and” and “or” if you aren’t
supposed to use them?
The problem for most people is that they fail to realize that they are
not aliases for && and || respectively.
Since they are not aliases they provide different functionality and
someone interested in programming with Ruby should research when and
how to use them. Again, Jan E. Came up with a good example.
One thing that I don’t like with ruby precedence however, is that ruby
developers decided to give “and” and “or” the same precedence.
In my opinion, “or” should have lower precedence than “and”, just like
in perl, wich allows you to do things like:
if <e_1> and <e_2> or <e_3> and <e_4>
Knowing that expression 3 and 4 will only be executed if 1 and 2 are
not true.
I suppose that they went for left to right readability so you have to
evaluate everything as you read it.
so to get something similar in ruby you have to write:
if (<e_1> and e_2>) or (<e_3> and <e_4>)
–DavidG
PS: why is there not (or at least an easy to find) an operator
precedence table in ruby-doc.com?
The ones I found where in different, not official looking websites.
Consider the difference between “x = true && false” and “x = true and
false”. Since && has HIGHER precedence than =, “x = true && false” is
equivalent to “x = (true && false)”, just as you might expect.
Why would I expect that? Why would I even use assignments in “if”
statements?
Sorry, but if you use assignments in “if” statements (much too obscure)
without explicit parenthesis (even worse), then I’d say this is your
problem, not the implicit operator precedence you somehow consider to be
“wrong”.
Maybe my programming style is totally out of fashion, but my “if”
statements usually look like this:
if and ( or )
…
end
With being a pure expression (no change of state). In
that context, I want a very low precedence to make sure that each is evaluated before and/or takes action.
And I believe this is the sane way of writing “if” statements.
When I want to do “magic” like
var = val || alt
then I do use &&/||. But this is a very different context.
What I do not like about this approach is that the used operators
depend on the context (condition in if statement / condition assigned
to a variable), not on the purpose (condition vs. control flow).
What reason is there for Ruby to have “and” and “or” if you aren’t supposed
to use them?
Just because it’s there, doesn’t mean it’s good. For instance, why
would the world have cold germs if we weren’t supposed to catch them?
(Yeah, I know, catching a cold is a good thing, from the POV of a cold
virus.) Heck, I’ve got a presentation with over a dozen nasty little
gotchas in Ruby.
One thing that I don’t like with ruby precedence however, is that ruby
developers decided to give “and” and “or” the same precedence.
Yeah, that’s very inconsistent with && vs. ||. Yet more reason not to
use them.
There’s only one time I can think of where I use “or” for the sake of
readability. I’ll often have a main method call a series of other
methods, each of which returns a boolean, and sets the error level as a
way of reporting failure. That is then passed to the errorhandler. This
leads to some simple lines like this:
boolean_return_method or fail
There is already too much written about using return values for error
handling. So I’ll only say that I don’t think this kind of design is
good.
Why would I expect that? Why would I even use assignments in “if”
statements?
Sorry, I missed that you were specifically speaking of “if”
statements. But even so:
Using &&/|| in some parts and and/or in other parts, is confusing and
fragile. If I have to make a complex boolean expression, and
something goes wrong, I sometimes extract parts out into an assignment
to a temp var, so I can grab that subexpression in a debugger. If
that subexpression uses and/or, that will play merry hell with trying
to get the actual value of the expression.
Sorry, but if you use assignments in “if” statements (much too obscure)
Agreed, and I said so even back in my days of hacking C, where it used
to be fairly common.
