Best practice for &&, ||, and, or

On Sat, Jan 5, 2013 at 11:46 PM, Jan E. [email protected] 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, [email protected] wrote:

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

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 T. написа:

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
[email protected], [email protected]
mobile:+359888761080,
phone:+35972366161, fax:+35972366262
Let’s make better business with http://www.redmine.org

On 6/01/2013, at 5:56 PM, Jan E. [email protected] 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

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 Mon, 07 Jan 2013 02:23:14 +0100, Henry M. [email protected]
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 01/05/2013 04:35 AM, [email protected] wrote:

the different precedences.

I tend to 1., and for own projects maybe to 3.

Regards,
Marcus

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 `’

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, Jan 7, 2013 at 12:39 AM, Joel P. [email protected]
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:

Kind regards

robert

Am 07.01.2013 03:34, schrieb Justin C.:

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 [email protected]:

Hi group,

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
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, [email protected] 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.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.