Home > Articles > Web Development

Accustoming Yourself to Ruby

  • Print
  • + Share This
In this excerpt from Effective Ruby: 48 Specific Ways to Write Better Ruby, Peter J. Jones examines Ruby's unique take on common programming ideas. That is, those that impact every part of your program, such as Treat All Objects as If They Could Be nil and Avoid Ruby’s Cryptic Perlisms.
This chapter is from the book

With each programming language you learn, it’s important to dig in and discover its idiosyncrasies. Ruby is no different. While it borrows heavily from the languages that preceded it, Ruby certainly has its own way of doing things. And sometimes those ways will surprise you.

We begin our journey through Ruby’s many features by examining its unique take on common programming ideas. That is, those that impact every part of your program. With these items mastered, you’ll be prepared to tackle the chapters that follow.

Item 1: Understand What Ruby Considers to Be True

Every programming language seems to have its own way of dealing with Boolean values. Some languages only have a single representation of true or false. Others have a confusing blend of types that are sometimes true and sometimes false. Failure to understand which values are true and which are false can lead to bugs in conditional expressions. For example, how many languages do you know where the number zero is false? What about those where zero is true?

Ruby has its own way of doing things, Boolean values included. Thankfully, the rule for figuring out if a value is true or false is pretty simple. It’s different than other languages, which is the whole reason this item exists, so make sure you understand what follows. In Ruby, every value is true except false and nil.

It’s worth taking a moment and thinking about what this means. While it’s a simple rule, it has some strange consequences when compared with other mainstream languages. In a lot of programming languages the number zero is false, with all other numbers being true. Using the rule just given for Ruby, zero is true. That’s probably one of the biggest gotchas for programmers coming to Ruby from other languages.

Another trick that Ruby plays on you if you’re coming from another language is the assumption that true and false are keywords. They’re not. In fact, they’re best described as global variables that don’t follow the naming and assignment rules. What I mean by this is that they don’t begin with a “$” character, like most global variables, and they can’t be used as the left-hand side of an assignment. But in all other regards they’re global variables. See for yourself:

irb> true.class
---> TrueClass

irb> false.class
---> FalseClass

As you can see, true and false act like global objects, and like any object, you can call methods on them. (Ruby also defines TRUE and FALSE constants that reference these true and false objects.) They also come from two different classes: TrueClass and FalseClass. Neither of these classes allows you to create new objects from them; true and false are all we get. Knowing the rule Ruby uses for conditional expressions, you can see that the true object only exists for convenience. Since false and nil are the only false values, the true object is superfluous for representing a true value. Any non-false, non-nil object can do that for you.

Having two values to represent false and all others to represent true can sometimes get in your way. One common example is when you need to differentiate between false and nil. This comes up all the time in objects that represent configuration information. In those objects, a false value means that something should be disabled, while a nil value means an option wasn’t explicitly specified and the default value should be used instead. The easiest way to tell them apart is by using the nil? method, which is described further in Item 2. Another way is by using the “==” operator with false used as the left operand:

if false == x

With some languages there’s a stylistic rule that says you should always use immutable constants as the left-hand side of an equality operator. That’s not why I’m recommending false as the left operand to the “==” operator. In this case, it’s important for a functional reason. Placing false on the left-hand side means that Ruby parses the expression as a call to the FalseClass#== method (which comes from the Object class). We can rest safely knowing this method only returns true if the right operand is also the false object. On the other hand, using false as the right operand may not work as expected since other classes can override the Object#== method and loosen the comparison:

irb> class Bad
       def == (other)
irb> false == Bad.new
---> false
irb> Bad.new == false
---> true

Of course, something like this would be pretty silly. But in my experience, that means it’s more likely to happen. (By the way, we’ll cover the “==” operator more in Item 12.)

Things to Remember

  • Every value is true except false and nil.
  • Unlike in a lot of languages, the number zero is true in Ruby.
  • If you need to differentiate between false and nil, either use the nil? method or use the “==” operator with false as the left operand.
  • + Share This
  • 🔖 Save To Your Account