Jones Peter. - Effective Ruby: 48 Specific Ways to Write Better Ruby

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

We begin our journey through Rubys 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, youll be prepared to tackle the chapters that follow.

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. Its 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 exceptfalse and nil.

Its worth taking a moment and thinking about what that means. While its 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. Thats probably one of the biggest gotchas for programmers coming to Ruby from other languages.

Another trick that Ruby plays on you if youre coming from another language is the assumption that true and false are keywords. Theyre not. In fact, theyre best described as global variables that dont follow the naming and assignment rules. What I mean by that is that they dont begin with a $ character like most global variables and they cant be used as the left-hand side of an assignment. In all other regards though, theyre 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 allow 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, you dont need the true object in order to return 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 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 wasnt 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
...
end

With some languages theres a stylistic rule that says you should always use immutable constants as the left-hand side of an equality operator. Thats not why Im recommending false as the left operand to the == operator. In this case, its 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 that 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)
true
end
end
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 its more likely to happen. (By the way, well get more into the == operator in Item 12.)

Every value is true exceptfalse 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.

Every object in a running Ruby program comes from a class that, in one way or another, inherits from the BasicObject class. Imagining how all these objects relate to one another should conjure up the familiar tree diagram with BasicObject at the root. What this means in practice is that an object of one class can be substituted for an object of another (thanks to polymorphism). Thats why we can pass an object that behaves like an arraybut is not actually an arrayto a method which expects an Array object. Ruby programmers like to call this duck typing. Instead of requiring that an object be an instance of a specific class, duck typing shifts the focus to what the object can do, in other words, interface over type. In Ruby terms, duck typing means you should prefer using the respond_to? method over the is_a? method.

In reality though, its rare to see a method inspect its arguments using respond_to? in order to make sure it supports the correct interface. Instead, we tend to just invoke methods on an object and if the object doesnt respond to a particular method, we leave it up to Ruby to raise a NoMethodError exception at runtime. On the surface, it seems like this could be a real problem for Ruby programmers. Well, just between you and me, it is. Its one of the core reasons testing is so very important. Theres nothing stopping you from accidentally passing a Time object to a method expecting a Date object. These are the sorts of mistakes we have to tease out with good tests. And thanks to testing, these types of problems can be avoided. Theres one particular kind of these polymorphic substitutions, however, that plagues even well tested applications:

undefined method `fubar' for nil:NilClass (NoMethodError)

This is what happens when you call a method on an object and it turns out to be that pesky nil object, the one and only object from the NilClass class. Errors like this tend to slip through testing only to show up in production when a user does something out of the ordinary. Another situation where this can occur is when a method returns