DEV Community

Juan Manuel Ramallo
Juan Manuel Ramallo

Posted on • Originally published at 1ma.dev

I don't use nil

I don't use nil, or at least I try not to.

NoMethodError: undefined method 'some_method' for nil:NilClass
Enter fullscreen mode Exit fullscreen mode

This is one of the most common errors seen on production systems. And it's likely to happen everywhere where a variable can reference to a null value. Here are some case studies about the topic.

Migrations

When creating/updating a table I always consider adding a null: false constraint and a default value accordingly. For string values, the default would be an empty string. For number values, the default value would be zero.

This allows us to do operations with those columns without worrying about them being nil, because we took care of that at the database level. For instance, let's consider a Post model in a blogging system:

# db/migrate/...
class CreatePosts < ActiveRecord::Migration[6.0]
  def change
    create_table :posts do |t|
      # [snip]

      # not bad
      t.string :excerpt

      # better
      t.string :excerpt, null: false, default: ''
    end
  end
end

# app/views/posts/show.html.erb
<p>
  <%= @post.excerpt.downcase %>
</p>
Enter fullscreen mode Exit fullscreen mode

In this particular example, sending downcase to Post#excerpt will always work because we ensured that the value will always return a String object.

Enums

Let's consider that any post can have a certain category. Since these categories won't have any extra info nor behavior, we'll use an enum attribute in the post model.

# db/migrate/...
class CreatePosts < ActiveRecord::Migration[6.0]
  def change
    create_table :posts do |t|
      # [snip]

      # not bad
      t.integer :category

      # better
      t.integer :category, null: false, default: 0
    end
  end
end
Enter fullscreen mode Exit fullscreen mode

We can easily add a default enum option to represent a post without a category. And why is it better? For the simple reason that the Post#category method will always return the same object type. This will cause the code to avoid checking for nil when working with the category, and will also make the safe navigational operator useless when working with this attribute.

# app/models/post.rb
class Post < ApplicationRecord
  enum category: { general: 0, lifestlye: 1, art: 2, misc: 3 }
end
Enter fullscreen mode Exit fullscreen mode

In this example we are using the category named general as the default one.

NullObject

This approach is an elegant way to represent a null value. It is somewhat similar to the enum's case study. Here's an excellent article from thoughtbot about this pattern.

undefined method 'conclusion' for nil:NilClass

To sum up, I don't use nil because I don't want the program to potentially raise this NoMethodError. To avoid it, it's just as easy as not handling null values in the codebase.

And this is Tony Hoare, the inventor of nil:

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years. src

Top comments (5)

Collapse
 
afrodevgirl profile image
Alexis Moody

I tend to agree that if you can control the schema it's best to have as few empty values as possible. But rails apps are often complex and can contain a number of integrations where the data shape can be variable. So I often find myself using &. and a combination of .blank? and .present? to ensure I don't have nil method errors. Personally, I'd rather be defensive most of the time so my programming brain does less context switching between languages. That said, I always support whatever delivers great value to users :)

Collapse
 
andrewmcodes profile image
Andrew Mason

Sandi Metz has a great talk on the Null Object Pattern if anyone wants to hear a great explanation of it.

Collapse
 
mpressen profile image
Maximilien Pressensé

I totally agree and tend to do as so in my own code.
Checking for nil or using safe navigator doesn't produce 'clean' code.
Great sum up.

Collapse
 
vlasales profile image
Vlastimil Pospichal • Edited

I use NULL in databases because it's something different than 0 or "". However, I do not use NIL in the application.

Collapse
 
wrldwzrd89 profile image
Eric Ahnell

Even in other languages, this pattern is VERY much worth following. Its impact is increased in Objective-C thanks to the way the language works.