Ruby Refactoring: Ugly Null Checking

When you can, always try to use the Null Object Pattern; however, there are times that may prove difficult. This doesn’t mean you need to abandon all readability though. Here is a block of code I ran into today that was improved with a little refactoring TLC.

Before

items.each do |item|
next unless item.widget
update_widget! item.widget
end

After

items.each do |item|
next if item.widget.nil?
update_widget! item.widget
end

Just because nil is conveniently falsey doesn’t mean it’s always best to treat it that way. Compare the before and after blocks above. Which has clearer intent on why next is called? I’m sure if you read it a bit the first makes sense, but the whole point is to avoid the necessity of reading code that much to figure out what it’s doing.

This is one of the cooler idioms I love about Ruby. nil? is baked into nil to be true and on Object, everything else, it’s false. Using this makes your code more readable, use it every chance you get instead of that ugly null boolean check!

Comments