[deleted]
Ruby Demystified: and vs. &&
21–30 of 74 posts
Re: Ruby Demystified: and vs. &&
#22[deleted]
Re: Ruby Demystified: and vs. &&
#23> When I first started learning Ruby, I was excited to discover that Ruby has the keywords and and or as boolean operators. I quickly got into the habit of writing all of my boolean statements with these, instead of the more conventional && and ||, because my code became so much readable pry(main)> a = true && false pry(main)> a = true and false Hmm...I dunno, I don't think the latter is necessarily easier to read th…
This article isn't about replacing symbols with words, ruby isn't about replacing symbols with words either, and there is no place in the article where the author states that a = true and false is prettier than a = true && false And if you would actually have read the article and paid close attention you would have learned that the two lines you just said are not functionally equivalent. No ruby programmer would ever…
If by "no place" you mean "first paragraph", you're right:
> I quickly got into the habit of writing all of my boolean statements with these, instead of the more conventional && and ||, because my code became so much readable.
And I definitely agree with danso and disagree with the blog on this issue: the operators gives more structure to the code and makes it much easier to parse at a glance. With the 'and' version, I have to actually read the code to figure out what its doing; with the '&&' version, I can get the basic idea just from the code's "shape" (for lack of a better word).
I think being able to quickly grasp the idea at a glance is far more important than having code look like English.
Re: Ruby Demystified: and vs. &&
#24Re: Ruby Demystified: and vs. &&
#25Re: Ruby Demystified: and vs. &&
#26Re: Ruby Demystified: and vs. &&
#27If this will help the brogrammers and fauxgrammers in the ruby world to take security and software engineering seriously, then it is a good thing.
Re: Ruby Demystified: and vs. &&
#28> When I first started learning Ruby, I was excited to discover that Ruby has the keywords and and or as boolean operators. I quickly got into the habit of writing all of my boolean statements with these, instead of the more conventional && and ||, because my code became so much readable pry(main)> a = true && false pry(main)> a = true and false Hmm...I dunno, I don't think the latter is necessarily easier to read th…
This article isn't about replacing symbols with words, ruby isn't about replacing symbols with words either, and there is no place in the article where the author states that a = true and false is prettier than a = true && false And if you would actually have read the article and paid close attention you would have learned that the two lines you just said are not functionally equivalent. No ruby programmer would ever…
there is no place in the article where the author states that a = true and false is prettier than a = true && false
Something like this, you mean?
I was excited to discover that Ruby has the keywords and and or as boolean operators. I quickly got into the habit of writing all of my boolean statements with these, instead of the more conventional && and ||, because my code became so much readable
If you would actually have read the article (or even just the comment you replied to) and paid close attention you would have learned that it said precisely that.
Re: Ruby Demystified: and vs. &&
#29tldr: && has higher operator precedence than "and" Significantly, "&&" > "=" > "and", which can lead to unintended results when refactoring "&&" --> "and"
I.E.: why you should always use && instead of "and".
To avoid a potentially useful language feature because you might make a mistake with it is, to me, a absurd.
A much better argument might be Use only when you fully grasp its use, which is true of any feature. Some are more difficult to understand than others, especially when trying to relate a feature to another language, but that's just not an argument I can support.
Re: Ruby Demystified: and vs. &&
#30Not to start a language war, but this blog post demonstrates two things Python got right that Ruby got wrong. First, in Python, there's only one way to express a boolean "and". The && operator is left out. Second, this post demonstrates a danger of allowing assignment via '=' evaluate to an expression (granted with less weird precedence rules it wouldn't turn out as bad in this case).
Whether right or wrong, I personally prefer the Python way and I'm not a particular fan of Tim Toady. Especially when working in teams, it's simply easier if you don't have to make up rules, but it's clear upfront what to use, because there is no need for discussion.