Is Ruby really trying to tell me that true and false evaluates to true? Nope. It turns out Ruby just has different precedence rules for and and &&. Now, this example may prompt you to avoid the word versions of the boolean operators altogether, and you wouldn’t be alone — the first Google result when searching “Ruby Style Guide” suggests you should never use them. But I say fear not, as and and or do have their ideal uses. They are much easier to understand if you stop thinking about them as boolean operators and start thinking of them as control flow operators! Allow me to explain.
The first edition of the Pragmatic Programmer’s book on Ruby has an excellent table listing the order of operations. It’s old and talks about Ruby 1.6, but we’re at Ruby 1.9.3 right now and the rules haven’t changed, and they likely won’t change for a long time. As you can see, and is really just a low-precedence version of &&. Its main purpose is to control the flow of logic, since its low precedence and short-circuiting behavior help ensure that all of its left-hand side gets evaluated before any of the right-hand side does. This is useful when you want to chain operations together and have them execute until one of them returns a false-y value (false or nil).
Let’s revisit the above example with this behavior in mind. Using parentheses to illustrate the order of operations, the following illustrates how && and and operate differently.