&& and and are NOT synonyms.
The old pickaxe made that clear too, like in 2004 already or so.
Perhaps the official documentation could mention this more clearly. Admittedly
I knew about this primarily (and initially) because I read the pickaxe back in
the days.
foo = some_value || other_value && third_value or raise "No branch have
produced really good value"
That's why those operators have the lowest possible precedence -- to be
performed definitely AFTER the rest of the statement.
I am not entirely sure that this would have the be the main (or only) use
case, but it was of course a deliberate decision. Changing this would not
have a massive net benefit in my opinion, well aside from backwards
incompatibility issues.
Personally I dislike complicated decision chains such as the above. My brain needs
to understand what is going on and it always takes me needlessly long to "decode"
what the intent is. I understand that people want to be concise and super short in
the code that they write, which is fine, but the world is not going to run out of
\n newlines any time soon. Then again, the style of different ruby users can be vastly
different and it is quite natural to prefer one style over another.
I really like this feature, but should also say that confusion about && vs
and is so high, that they are banned explicitly by Bozhidar Batsov's "Ruby
Style Guide" (for context: very heated discussion), and even half of the
standard library uses and and or in boolean context.
Well, let's for the moment ignore confusion and style guide - I think the
only practical approach about this is to provide people with sufficient
information via the main entry site (for the ruby documentation). Because
the ruby documentation, while it is ok, is still not really great. One
reason why the pickaxe was so useful, at the least to me back in the days,
was primarily because it put a lot of information into one place, and it
was easy to read, and quite detailed. The official documentation on the
other hand was ... hmm. A bit more boring to read, and not quite on the
same level of quality, IMO.
Of course the official documentation also has other goals, such as being a "fast
reference", so it won't explain a lot about style issues, or how to write code;
but still, some things, such as the "&&" versus "and", could probably also be
explained better on the main documentation.
Personally my two main style guides are the subjective quality analysis
by my brain :) and what the ruby parser allows. I don't use other style
guides per se, although rubocop has several other benefits in my opinion
such as auto-correct. But to refer specifically to "and" versus "&&" -
while I do not agree that any "guide" should "ban" anything, ever, when
the ruby parser instead accepts it, I think that in many ways "and" is
easier to read. People are of course very used to &&, but in my opinion
"and" often leads to nicer-to-read code. I have not made any statistical
analysis in my own code, but I can tell you off the top of my head that
I vastly use "and", as opposed to "&&". I don't have any clear policy of
banning or not banning, but just my "natural" flow of writing ruby code
clearly favours "and". (That also means that I may have to use () more
often but I am fine with that.)
What may be interesting, though well aside from this issue, may be to
perform some statistical analysis in general, as to what different ruby
users may use, e. g. in their own code base (or at the least the gems
published on rubygems.org). Although I have no data to prove anything,
my intuition says that "and" is used a lot more often in ruby code
these days. But I could be wrong, too - really just guessing/guestimating
here.
even half of the standard library uses and and or in boolean context.
Well, we need to remember that different people contributed code, and
very old ruby code often looks quite different from "modern" ruby code
aka written in the last ~3 years.
By the way, last but not least - the old pickaxe also mentioned that irb
behaves a bit differently from the main ruby parser. I guess daBee did not
read the pickaxe, which may also be a question of time (people today are
probably less likely to read the pickaxe, as compared to e. g. the year
2006 or so). The best approach, IMO, would be to improve on the documentation
whenever people don't seem to find what they wanted to know or tried to
figure out / understand.