Forum: Ruby Best practice for &&, ||, and, or

Hi group,

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:

   1. use only &&, ||
   2. use only `and', `or'
   3. distinguish between boolean expressions (if this && that)
      and control flow (loot = give_money  or die)
   4. ???

1. 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 tend to 1., and for own projects maybe to 3.

Regards,
Marcus


[1] https://github.com/styleguide/ruby/

Hello,

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.

Just my two cents.

Regards,
Calvin

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.)"

Excerpt from: https://github.com/bbatsov/ruby-style-guide

Am 05.01.2013 17:25, schrieb Joel Pearson:
> 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.)"
>
> Excerpt from: https://github.com/bbatsov/ruby-style-guide
>

Maybe(?) worth mentioning that the Github Ruby Styleguide, though based
on the guide cited by you, explicitly differs in this point.

unknown wrote in post #1091146:
> Am 05.01.2013 17:25, schrieb Joel Pearson:
>> 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.)"
>>
>> Excerpt from: https://github.com/bbatsov/ruby-style-guide
>>
>
> Maybe(?) worth mentioning that the Github Ruby Styleguide, though based
> on the guide cited by you, explicitly differs in this point.

Good point, actually I think I nearly always use && ||. To be fair I 
think all my flow control ends up boolean anyway.

On Sat, Jan 5, 2013 at 7:35 AM,  <sto.mar@web.de> wrote:

> 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

This can help you: http://rubylearning.com/images/operators.jpg
 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.

Am 05.01.2013 22:57, schrieb Damián M. González:
> This can help you: http://rubylearning.com/images/operators.jpg
>   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.

Dave Aronson wrote in post #1091164:
> On Sat, Jan 5, 2013 at 7:35 AM,  <sto.mar@web.de> wrote:
>
>> 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:

boolean_return_method or fail

Hi,

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?

On Sat, Jan 5, 2013 at 5:46 PM, Jan E. <lists@ruby-forum.com> wrote:

> 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.
;-)

-Dave

Dave Aronson wrote in post #1091178:
> 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.

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 <some expression> and (<some expression> or <some expression>)
  ...
end

With <some expression> being a pure expression (no change of state). In 
that context, I want a very low precedence to make sure that each <some 
expression> 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.

Am 06.01.2013 05:56, schrieb Jan E.:
> Dave Aronson wrote in post #1091178:
>> 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.
>
> 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 <some expression> and (<some expression> or <some expression>)
>    ...
> 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

No "magic" is involved here.

Regards,
Marcus

On Sat 05 Jan 2013 09:56:38 PM MST, Jan E. wrote:
> 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.
1. http://phrogz.net/ProgrammingRuby/language.html#table_18.4
2. http://www.tutorialspoint.com/ruby/ruby_operators.htm

Am 06.01.2013 09:43, schrieb David Gamba:
> One thing that I don't like with ruby precedence however, is that ruby
> developers decided to give "and" and "or" the same precedence.

But note that && has higher precedence than ||.

unknown wrote in post #1091194:
> Am 06.01.2013 09:43, schrieb David Gamba:
>> One thing that I don't like with ruby precedence however, is that ruby
>> developers decided to give "and" and "or" the same precedence.
>
> But note that && has higher precedence than ||.

Exactly.  If && has higher precedence than ||, why "and" does not have
higher precedence than "or"?

Regards,

Bill

Am 06.01.2013 15:21, schrieb Admin Tensor:
> Regards,
>
> Bill

ask Matz :)

On Sat, Jan 5, 2013 at 11:56 PM, Jan E. wrote:

> 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.

-Dave

On Sun, Jan 6, 2013 at 3:33 AM,  <sto.mar@web.de> wrote:

> 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).

Exactly.

On Sun, Jan 6, 2013 at 3:43 AM, David Gamba <davidgamba@gmail.com> 
wrote:

> 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.

-Dave

On Sat, Jan 5, 2013 at 11:29 PM, Joel Pearson <lists@ruby-forum.com> 
wrote:

> 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.

Kind regards

robert

On Sat, Jan 5, 2013 at 11:46 PM, Jan E. <lists@ruby-forum.com> wrote:

> 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?

Jan, I am not totally sure what you mean by this.  In any case (&& or
and) the left expression is evaluated before the operator and operator
and boolean result of that left expression evaluation determine
whether the right hand expression is evaluated _at all_.

irb(main):001:0> def t(x)p x end
=> nil

irb(main):002:0> t(false) and t(nil)
false
=> false
irb(main):003:0> t(false) && t(nil)
false
=> false

irb(main):004:0> t(1) or t(2)
1
=> 1
irb(main):005:0> t(1) || t(2)
1
=> 1

irb(main):007:0> t(1) and t(false)
1
false
=> false
irb(main):008:0> t(1) && t(false)
1
false
=> false

irb(main):009:0> t(false) or t(2)
false
2
=> 2
irb(main):010:0> t(false) || t(2)
false
2
=> 2

Precedence only indirectly affects execution order by means of
grouping of expressions.

Kind regards

robert

On Sat, Jan 5, 2013 at 1:35 PM,  <sto.mar@web.de> wrote:

> So what's your practice/recommendation:
>
>   1. use only &&, ||
>   2. use only `and', `or'
>   3. distinguish between boolean expressions (if this && that)
>      and control flow (loot = give_money  or die)
>   4. ???

3 - for both.  Why should I recommend teaching a practice I don't
follow.  Then I'd rather explain only "&&" and "||", mention that
there are also other boolean operators but that I'll cover them later
in the tutorial etc.

Kind regards

robert

Am 06.01.2013 17:47, schrieb Robert Klemme:
> 3 - for both.  Why should I recommend teaching a practice I don't
> follow.

Because beginners (in my case high school students with zero programming
experience) are lacking the knowledge and experience you have.
They might be completely unable to grasp and especially internalize
the subleties and gotchas that are involved here.

> Then I'd rather explain only "&&" and "||", mention that
> there are also other boolean operators but that I'll cover them later
> in the tutorial etc.

Exactly. This discussion has confirmed my tendency to only teach
&&, || (for boolean expressions, assignments with defaults, ...)
and leave control flow to if/unless.

Myself, I use constructs like `do_something or do_other'
very seldom anyway.

unknown wrote in post #1091219:
> Exactly. This discussion has confirmed my tendency to only teach
> &&, || (for boolean expressions, assignments with defaults, ...)
> and leave control flow to if/unless.
>
> Myself, I use constructs like `do_something or do_other'
> very seldom anyway.

Yup.  The way && and || work is like almost all other languages.  But
because "and" and "or" has lower precedence and "and" has the same
precedence as "or", I almost never use them.  (If you switch from
language to language, you know what I mean.)

Regards,

Bill

На 6.1.2013 г. 21:30 ч., Admin Tensor написа:
> language to language, you know what I mean.)
>
> Regards,
>
> Bill
>
Hi,
I am a C programmer and have to comply the code with MISRA
<http://en.wikipedia.org/wiki/MISRA_C> rules.
According to these rules programmers should not rely on precedence of 
the
operators. They state to use [redundant] parenthesizes () instead.
So when an expression is too complicated, ( and ) would be in help.

--

Regards,

Ivan Cenov
OKTO-7 Co. Bulgaria
imc@okto7.com, i_cenov@botevgrad.com
mobile:+359888761080,
phone:+35972366161, fax:+35972366262
Let's make better business with http://www.redmine.org

> 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.
>
> Kind regards
>
> robert

Would you be able to point me in the direction of some of these 
writings? I'm always interested in improving my code.

On 6/01/2013, at 5:56 PM, Jan E. <lists@ruby-forum.com> wrote:

> 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".


Couldn't disagree with you MORE.
Assigning the result of an expression is very Rubyish. Assigning the 
result of an if statement is an elegant way of eliminating redundant 
assignments.


x = if y && z
  1
else
  2
end

vs

x = 0

if y && z
  x = 1
else
  x = 2
end

I agree that "and" / "or"  are used for flow control NOT logical 
expressions.

Henry

On 01/05/2013 04:35 AM, sto.mar@web.de wrote:
> So what's your practice/recommendation:
> the different precedences.
>
> I tend to 1., and for own projects maybe to 3.
>
> Regards,
> Marcus
>
>
> [1] https://github.com/styleguide/ruby/
>

I think I'm in the minority here, so I'll give my minority opinion: For
my own projects I prefer and/or and only use &&/|| for assignments.
Looking through one of my codebases, I see 312 uses of "and" and 8 uses
of "&&" (mostly from other contributors).

Why? Because I also dislike using parentheses for method calls, which
again seems to be becoming a minority preference. (Also, by default vim
highlights and/or but not &&/|| and I like pretty colors.)

irb(main):001:0> def x *args; true; end
=> nil
irb(main):002:0> def y *args; true; end
=> nil
irb(main):003:0> if x 1 and y 2
irb(main):004:1>   puts "all good"
irb(main):005:1> end
all good
=> nil
irb(main):006:0> if x 1 && y 2
irb(main):007:1>   puts "not all good"
irb(main):008:1> end
SyntaxError: (irb):6: syntax error, unexpected tINTEGER, expecting
keyword_do or '{' or '('
(irb):8: syntax error, unexpected keyword_end, expecting $end
  from /home/justin/.rvm/rubies/ruby-1.9.3-p327/bin/irb:12:in `<main>'


I haven't spent much time teaching others, so I don't really have an
opinion on that. I assume those coming from other languages would be
more comfortable with &&/||.

I also prefer to use "not" because that stands out more to me than "!".

-Justin

On Mon, 07 Jan 2013 02:23:14 +0100, Henry Maddocks <hmaddocks@me.com> 
wrote:

> Couldn't disagree with you MORE.
> Assigning the result of an expression is very Rubyish. Assigning the result of 
an if statement is an elegant way of eliminating redundant assignments.

You're confusing assigning the result of an if with an assignment within 
an if. It's the second people are having problems with.

On Mon, Jan 7, 2013 at 12:39 AM, Joel Pearson <lists@ruby-forum.com> 
wrote:
>> 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.

> Would you be able to point me in the direction of some of these
> writings? I'm always interested in improving my code.

I don't have a specific article in mind, but there are plenty:
https://www.google.com/search?q=exceptions+vs+return+codes

Kind regards

robert

Am 07.01.2013 03:34, schrieb Justin Collins:
> Why? Because I also dislike using parentheses for method calls, which
> again seems to be becoming a minority preference. (Also, by default vim
> highlights and/or but not &&/|| and I like pretty colors.)
>
> irb(main):001:0> def x *args; true; end
> => nil
> irb(main):002:0> def y *args; true; end
> => nil
> irb(main):003:0> if x 1 and y 2

I could not write that line and still sleep at night... :)

Am 05.01.2013 13:35, schrieb sto.mar@web.de:
> Hi group,
>
> 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".

Thanks to all for your interesting input.

To sum up: I have come to the conclusion to ban 'and'/'or' completely
from my teaching (except for mentioning their existence).
In the limited time I have I can only discuss a small subset
of the Ruby language anyway, and flow control with 'and'/'or'
rather falls in the category of syntactic sugar, especially for
a beginner.

I have been confirmed in the believe that 'and'/'or' for logical
expressions -- though very readable -- is just BAD and dangerous,
because the behavior is too surprising.
A student (and maybe not only a student) might happily refactor

   if cond1 and cond2
     ...
   end

to

   condition = cond1 and cond2
   if condition
     ...
   end

without ever noticing that this would break the logic of the code.

I still might use 'and'/'or' for flow control in my personal projects,
but I use this idiom very seldom anyway and rather prefer if/unless.

Regards,
Marcus

On Fri, Jan 11, 2013 at 10:34 AM,  <sto.mar@web.de> wrote:
>     ...
>   end
>
> without ever noticing that this would break the logic of the code.

This is a *very* good point -- one which I had not considered. Even if
*I* understand how they work, the next person (or n-th person) looking
at my code might not. Now I really do understand the choice in the
style guide. I personally have not used and/or in if/unless
statements; I've only used them for control. But now I'm finding using
if/unless to manage the control much clearer, and using and/or in that
way does begin to seem more like a side-effect. I'm joining the ban
the and crowd.