there are bugs in if-statements using and.
#967
Conversation
|
Is there an example of a situation where one of these resulted in a wrong output? |
|
For example, this is always true if |
|
That would be a surprising result, but I'm not able to reproduce that in a simple |
|
Oh, really...? Simply we can check it as follows: Both we get are true. So we must say that the codes using |
|
First, I would agree that using Your example is incorrect, mostly because x = :pure_ruby
if true and x == :pure_ruby
p 'true'
else
p 'false'
end
if true and x != :pure_ruby
p 'true'
else
p 'false'
end |
|
Thanks @MSP-Greg, exactly the explanation for this situation of using @mephistobooks I would be glad to take the PR for modern Ruby style if you would clarify the commit message to say that this is a style change not a bug-fix. |
a309b11 to
a3fb762
Compare
…. "The Ruby Style Guide")
a3fb762 to
ba99be5
Compare
|
FWIW, although I agree with every change in this PR, I resent the ruby style guide total ban. And the justification confuses more than it clarifies (basically: it's FUD). So I'm just registering that complaint. 😜 Avdi Grimm has a good explanation (transcript available at the unlinkable "Video Script" tab). But, Avdi and I both learned Perl before ruby. Fortunately, the rubocop default is Contrary to what the style guide says: ruby's precedence makes more sense than Perl's (IMO), once you understand the design rationale. 🙂 It makes perfect sense for boolean algebra symbols to follow the standard math precedence rules (disjunctive normal form, or the sum of products) and the English control flow words to follow the most common linguistic approach (simple left-to-right). If you want restrictions on the more arcane corners of ruby's grammar: using parens on most method calls is more helpful (and maybe less controversial?). The way "command_call" interact with "stmt", "expr", "arg", and "primary" isn't always obvious until you've spent time playing with the grammar. And to be fair, ruby's core syntax rdoc really should do a better job of explaining all of this. Anyway, everyone's time might've been better served if, instead of writing this comment, I had submitted PRs to the ruby style guide and ruby's |
the operators of
and,or, andnotin if-statements are too buggy.(ex.
p true and false=>true)we should not use them. actually there are bugs in
eventmachine.rbso i correct them.please read this: "Ruby Style Guide", no
and/or.