Explicit vs. concise code in Ruby

by Werner Schuster on Jul 30, 2007 |
Piers Cawley writes about a potential problem he discovered in a blog article about Lazily Initialized Attributes. The problematic code:
def content
 @content ||= []
This is aimed to allow for lazily initialized attributes of a class. In this case, the @content instance variable is initialized with [] when it's accessor method content is called, unless it has already been initialized. The ||= operator means "if the left hand variable is nil, set it to the right hand value, otherwise just return the left hand variable's value".

However, as Piers points out, there is a problem with certain values due to the way Ruby treats boolean values and nil. Here an example to illustrate:
a = false
a ||= "Ruby"
What's the result of this? Since a was initialized in the first line, the second line should not have had any effect. However, executing that code reveals that a now has the value "Ruby", instead of false.

The problem becomes clear by remembering the common way to write nil checks in Ruby:
if name
 puts name.capitalize
In Ruby, a nil is interpreted as boolean false, so the code in the if clause will only run if the name is not nil.

While this is usually not a problem, in the lazily initialized attributes code, it's a problem if a legal value for attribute is either nil or false. In that case, an access would reset the variable to it's default value.

This is certainly a corner case, however it's the kind of issue that can cause long debugging sessions, trying to figure out why some attributes are occasionally reset while others aren't.

Piers offers a more explicit version of the code:
def content
 unless instance_variable_defined? :@content
 @content = []
return @content
This only initializes the variable if the variable hasn't been defined yet.

This little example could be blamed on Ruby and some of it's language features - but it's widely known which type of workers blame their tools instead of themselves. While the conciseness  of Ruby is very helpful, there are cases where more explicit expression of intent is safer. In this case, the ||= wasn't the right solution and instead the initialization code is supposed to check if the variable had been defined yet.

Have you been bitten by issues such as this one? Are there Ruby features you like to avoid to prevent subtle errors?

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Nice post by Stephan Schmidt

Nice post. Those bugs are nasty to find.

"... it's widely known which type of workers blame their tools ..." makes me laugh though.

I know a lot of people who blame Java because of their lack of productivity. And I know very few people who still write Mc68k/40 code.


Stephan Schmidt ::
Reposita Open Source - Monitor your software development
Blog at - No signal. No noise.

More Variable Metadata by John DeHope

I've often thought we need more metadata on our variables (or function arguments, or properties, etc). Currently we have just one: null. A reference can either be null, or have a value. I'd like to also have "defined" to say if a given name has been defined. "Initialized" can say if it has ever been set before, in which case the value could also be nil or non-nil. Also "null" can work just like it does now (or nil in Ruby, whatever). A hybrid "has value" concept would be nice too, which requires both "initialized" to be true and also "is null" to be false. With these constructs it would be possible to write very clear expressions such as "if x is initialized ..."

definitely a corner case. by matt mcknight

def content
@content ||= []

In what case could something return an array or false- n valued logic? Seems completely off base as a criticism.
100% of the time I use code like this it's to avoid doing nil? checks all over the code. If you are writing code where nil is an acceptable value, why would you need to initialize the array to empty? It seems odd to have a semantic difference between nil and empty array where nil is something that the array explicitly gets set to after it is initialized. A programmer would generally expect that nil means uninitialized. Now I have to check for nil every time I call:

In the case where you are actually dealing with a boolean, you don't have to do anything- the nil naturally works in conditional expressions.

Maybe I just need a better example to understand this particular point. I agree with the general thrust of the article- that sometimes being concise can obscure the meaning of the code, but I don't see this idiom as problematic. On the other hand- having 0 != false in Ruby is a bit weird, no pun intended.

Re: definitely a corner case. by Werner Schuster

The original article on "Lazily Initialized Attributes" ( ) where this issue was found, shows a general way to initialize attributes only when they're actually accessed.
So, this is not specific to lists, but generally to using this idiom for initializing attributes.

So, if you use this idiom to create a boolean attribute or an attribute that can be some value OR nil, then you can run into trouble.

class Foo
def red?
@red ||= true
def red=(arg)
@red = arg

x = # returns true, default value = false # @red is now false # returns ... true, because of the issue described in the article

Re: definitely a corner case. by matt mcknight

The trickiness in Jay's case is trying to lazy initialize a boolean to true. That's the only place one could actually run into a problem, but a simple nil check would work there. I still think the standard
@x ||= default

works except for cases where you want to initialize a boolean.

In any case, lazy initialization should probably only used for expensive operations, not for setting simple defaults.

Re: More Variable Metadata by matt mcknight

I think the distinction between nil? and empty? or blank? (a Rails addition) is more interesting area to explore. I think using or implementing those methods makes things more clear than setting something to nil and expecting that to mean empty, as opposed to uninitialized.

Re: definitely a corner case. by Piers Cawley

My point was that generic code should always consider the corner cases. Espcially with a pattern like this which can so easily be wrapped up in a method constructor. In code where you control the horizontal and the vertical there's nothing wrong with taking the view that you'll never trip over the nil/false problem, but in library code you must account for it.

Since a pattern is essentially a subroutine that's executed by a human being, it makes sense for the pattern to at least discuss the potential pitfall.

You mean I can't just turn off my brain? by Levi Cook

I have to admit to using ||= absentmindedly. Thanks for pointing out the gap in this idiom. I'm sure it was only a matter of time before I was bit by it.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

8 Discuss
General Feedback
Marketing and all content copyright © 2006-2016 C4Media Inc. hosted at Contegix, the best ISP we've ever worked with.
Privacy policy

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.