Syndication Icon
Published September 1, 2020 Updated September 20, 2020
Article Cover
Ruby Antipatterns

An antipattern is just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn’t one. — Andrew Koenig

The Ruby language is rich in functionality, expressiveness, and succinctness, a blend of object-oriented and functional styles. Because of this unique construction, Ruby can have sharp edges that make your codebase hard to read, debug, and maintain. The following dives into a few such aspects of the Ruby language that should be avoided in professional work. Don’t get me wrong! It’s fun to play with the following problematic examples as local experiments and/or explorations for personal or even debugging purposes. However, when it comes time to committing code that will be used for production purposes, these practices should be avoided.

Global Variables

Ruby has a collection of global variables which are borrowed from Perl and shell scripting in general. These can be viewed via the Kernel#global_variables method. A full description of all variables and their corresponding aliases can be found within the English library source code (i.e. require "English"). Here’s a rough breakdown of each:

$/       # Input record separator. Alias: $INPUT_RECORD_SEPARATOR. Default: newline. Deprecated in Ruby 2.7.0.
$.       # Current input line number of the last file read. Alias: $INPUT_LINE_NUMBER.
$\       # Output record separator. Alias: $OUTPUT_RECORD_SEPARATOR. Default: nil. Deprecated in Ruby 2.7.0.
$;       # String#split default field separator. Alias: $FIELD_SEPARATOR. Deprecated in Ruby 2.7.0.
$,       # Output field separator. Alias: $OUTPUT_FIELD_SEPARATOR. Deprecated in Ruby 2.7.0.
_$       # Input variable for each object within an IO loop.
$!       # Last exception thrown. Alias: $ERROR_INFO.
$@       # Backtrace array of last exception thrown. Alias: $ERROR_POSITION.
$&       # String match of last successful pattern match for current scope. Alias: $MATCH.
$`       # String to the left of last successful match. Alias: $PREMATCH.
$'       # String to the right of last successful match. Alias: $POSTMATCH.
$+       # Last bracket matched by the last successful match. Alias: $LAST_PAREN_MATCH.
$<n>     # nth group of last successful regexp match.
$~       # Last match info for current scope. Alias: $LAST_MATCH_INFO.
$<       # Object access to the concatenation of all file contents given as command-line arguments. Alias: $DEFAULT_INPUT.
$>       # Output destination of Kernel.print and Kernel.printf. Alias: $DEFAULT_OUTPUT. Default: $stdout.
$_       # Last input line of string by gets or readline. Alias: $LAST_READ_LINE.
$0       # Name of the script being executed. Alias: $PROGRAM_NAME.
$-       # Command line arguments given for script. Alias: $ARGV.
$$       # Ruby process number of current script. Alias: $PROCESS_ID or $PID.
$?       # Status of the last executed child process. Alias: $CHILD_STATUS.
$:       # Load path for scripts and binary modules via load or require. Alias: $LOAD_PATH.
$"       # Array of module names as loaded by require. Alias: $LOADED_FEATURES.
$-d      # Status of the -d switch. Alias: $DEBUG.
$-K      # Source code character encoding being used. Alias: $KCODE.
$-v      # Verbose flag (as set by the -v switch). Alias: $VERBOSE.
$-a      # True if option -a ("autosplit" mode) is set.
$-i      # In-place-edit mode. Holds the extension if true, otherwise nil.
$-l      # True if option -l is set ("line-ending processing" is on).
$-p      # True if option -p is set ("loop" mode is on).
$-w      # True if option -w is set (Ruby warnings).
$stdin   # Current standard input.
$stdout  # Current standard output.
$stderr  # Current standard error output.

You can also define and use your own global variables:

$example = "hello"
puts $example # => "hello"

While global variables are good to be aware of, it’s difficult to read and intuit their meaning — at least for predefined global variables that is. Requiring the English library will improve readability but doesn’t prevent the values from being mutated unless you remember to freeze them. Global variable usage breaks encapsulation as the variable can then be used anywhere within the program and even mutated, which leads to unexpected bugs, difficultly in debugging, and resolving issues.

A better approach is to reduce scope to the objects that need these values through dependency injection via default constants or even default configurations provided by gems like XDG or Runcom.

Class Variables

As briefly discussed in an earlier Refinements article, class variables behave a lot like global variables except they are scoped within their own class hierarchy rather than globally. For a closer look, consider the following:

class Parent
  @@example = "defined by parent"

  def self.print
    puts @@example
  end
end

class Child < Parent
end

Parent.print # => "defined by parent"
Child.print  # => "defined by parent"

Notice both the Parent and Child classes yield the same output, which seems reasonable until the following modification is introduced:

class Child < Parent
  @@example = "overwritten by child"
end

Parent.print # => "overwritten by child"
Child.print  # => "overwritten by child"

Not only did the Child define it’s own value but it mutated the Parent as well. If you haven’t seen this before, it can be an unpleasant surprise. A quick and dirty solution would be to instead use a class instance variable:

class Parent
  @example = "defined by parent"

  def self.print
    puts @example
  end
end

class Child < Parent
  @example = "defined by child"
end

Parent.print # => "defined by parent"
Child.print  # => "defined by child"

While the above is an improvement, a better approach would be remove state from classes altogether and encapsulate behavior in a barewords instance:

class Parent
  def initialize message = "parent default"
    @message = message
  end

  def print
    puts message
  end

  private

  attr_reader :message
end

class Child < Parent
  def initialize message = "child default"
    super
  end
end

Parent.new.print # => "parent default"
Child.new.print  # => "child default"

As an added bonus, you now have a way to construct multiple instances of each class with different default messages.

Nested Classes

You can nest classes within each other and still be able to reference them anywhere in your application without fear of being scoped only to the parent namespace. This behavior is very different from languages, like Java for example, where an inner class is scoped to the outer class only. Here’s an example:

class Outer
  class Inner
    def self.speak
      puts "HI"
    end
  end
end

Outer::Inner.speak # => "HI"

A module is similar to using a class:

module Outer
  class Inner
    def self.speak
      puts "HI"
    end
  end
end

Outer::Inner.speak # => "HI"

In both cases above, the difference is between Outer being defined as either a class or a module. Both are acceptable and both are constants that give structure to your code.

The problem with nested classes arises when you truly want to use modules to organize your code and stumble upon some random nested class in your code base that has the same name as your module. This can be frustrating from an organization and refactoring standpoint since Ruby code is typically organized in modules. Here’s an example, along with an associated error, in which we attempt use a module without realizing a class of the same name existed:

class Outer
  class Inner
  end
end

module Outer
  class Other
  end
end

# 6:in `<main>': Outer is not a module (TypeError)
# 1: previous definition of Outer was here

For this reason alone, it’s better to avoid nesting your classes and use module for organizing your code, reserving class for your actual implementation.

Subclassed Primitives

Primitives are objects like String, Array, Hash, etc. It can be tempting to implement an object by subclassing one of these primitives and adding your own custom behavior. For example, let’s make a subclass of Array:

class Example < Array
end

Example.new.class                  # => Example
Example.new.to_a.class             # => Array
(Example.new + Example.new).class  # => Array

Notice how the Example instances start out reasonable enough but then take a surprising turn. This is because core primitives are implemented in C for performance reasons where the return values of several methods, like #+, are hard coded to answer the super type. This is why we get an Array instead of Example. This can lead to subtle and surprising behavior. Even structs don’t want to be subclassed.

You can avoid hard to debug behavior, like this, by using composition instead of inheritance:

class Example
  include Enumerable

  def initialize(*arguments)
    @list = Array arguments
  end

  def each(*arguments, &block)
    list.each(*arguments, &block)
  end

  private

  attr_reader :list
end

example = Example.new 1, 1, 2
example.map { |element| element * 10}  # => [10, 10, 20]
example.min                            # => 1
example.max                            # => 2
example.tally                          # => {1 => 2, 2 => 1}

With the above, we get all the benefits of Enumerable — which is generally what you want — by implementing a single method: #each. Delegation by extending Forwardable, for example, is another viable option.

Even the object size is reduced:

Array.new.methods.size   # => 191
Enumerable.methods.size  # => 109

That’s a savings of 82 methods you most likely don’t need either. So, yeah, save yourself some heartache, use composition, and keep your objects simple.

Flat Modules

A flat module structure looks like this:

module One
end

module One::Two
end

module One::Two::Three
  puts Module.nesting # => [One::Two::Three]
end

Notice when we print the module structure at point of call we get a single element array: One::Two::Three. To contrast the above, here’s the result when defining nested modules:

module One
  module Two
    module Three
      puts Module.nesting # => [One::Two::Three, One::Two, One]
    end
  end
end

Now we have a three element array where each module in the hierarchy is a unique element in the array. Our object hierarchy is preserved so constant/method lookup is relative to the hierarchy. To illustrate further, consider the following:

module One
  EXAMPLE = "test"
end

module One::Two
end

module One::Two::Three
  puts EXAMPLE
end

# => uninitialized constant One::Two::Three::EXAMPLE (NameError)
# => Did you mean?  One::EXAMPLE

As the error above shows, we could use One::Example to solve the problem. To not repeat ourselves, use a nested module structure instead:

module One
  EXAMPLE = "test"

  module Two
    module Three
      puts EXAMPLE
    end
  end
end

Notice how the above is concise, removes duplication of the earlier example, and provides a unique constant for each level of the hierarchy for relative reference and lookup. Stick to nested modules so you can avoid needless implementation construction and unexpected errors.

Multi-Object Files

Ruby has no limitation with defining multiple objects per file, as shown in the following:

# demo.rb

module One
  module Two
  end
end

class Example
end

There are several disadvantages to this lack of limitation:

  • The One::Two module and Example class are defined in a demo.rb file which is not intuitive when searching for either via a fuzzy file search.

  • The implementation suffers from poor organization as none of the above are remotely related from a naming standpoint. Even if the objects were loosely related, it is better to isolate to a seperate file as mentioned in the previous bullet point.

  • The example above, while momentarily small, can get unwieldy to read/maintain if the size of each implementation grows in complexity.

Rather than multiple objects per file, a better solution would be to define each object in a separate file, like so:

# one/two.rb
module One
  module Two
  end
end
# example.rb
class Example
end

Organizing one object per file helps encourage a consistent structure and reduces the strain of finding the associated file with the implementation you are looking for.

Monkey Patching

Ruby has always allowed objects to be be monkey patched. Example:

class String
  def inspect
    "You've been hacked!"
  end
end

Monkey patching is hard to debug and can introduce surprising behavior, especially when patched deep within the internals of your application or some dependent library. Luckily, these unpleasant surprises can be safely avoided via Refinements, which were fully implemented in Ruby 2.1.0. This has been discussed in detail before, so follow the link to learn more.

Safe Navigation Operator

Introduced in Ruby 2.3.0, this operator is particularly egregious because it encourages several violations of good object oriented design. You can also think of this operator as the lazy operator. Example:

author = nil
author&.address&.street # => nil

The above violates all of the of the following:

  • Connascence of Name/Type - We now have a tight coupling to the names of the objects via the messages being sent. We also need to know the object hierarchy and types of objects we are messaging (i.e. address and street). If this code were to be refactored so the names and/or types changed, the above code snippet would still work. This false positive can be hard to detect if not thoroughly tested or, worse, discovered in production only.

  • Null Object - Instead of messaging the author for address and then street, address could answer back a null object that acts like an address but has safe default values. Same goes for street. At least, in this case, you’d be dealing with the same types of objects for validation purposes.

  • Law of Demeter - This harkens back to the connascence issue where we have to dig into the author and then address to pluck out the value of street. We could teach author to answer back the street address. Example: author.street_address. Now the underlying semantics can be refactored as necessary with the calling object being none-the-wiser. Even better, the Adapter Pattern could be used to consume an address and provide a #street_address message with the appropriate validation and error handling.

While there isn’t an automated way to discourage this practice entirely, you can disable the spread of this via Rubocop:

Style/SafeNavigation:
  Enabled: false

Numbered Parameters

These were introduced in Ruby 2.7.0. Here’s a simple example:

["Zoe Alleyne Washburne", "Kaywinnet Lee Frye"].each { puts _1 }

# Yields:
# Zoe Alleyne Washburne
# Kaywinnet Lee Frye

To improve readability, you could write it this way:

["Zoe Alleyne Washburne", "Kaywinnet Lee Frye"].each { |character| puts character }

While this solution requires more typing, good variable names help convey meaning and serve as a form of documentation. In this case, we’re not only printing names of people but we can see these are fictional characters. The value of this cannot be understated, especially if you were to iterate all enumerables using numbered parameters throughout your entire codebase. The use of _1, _2, _3, etc. would get monotonous quickly and make it hard to maintain context of each code block.

Nested blocks aren’t supported either because the following fails:

1.times do
  _1.times { puts _1 }
end

# Yields:
# SyntaxError...numbered parameter is already used in...outer block

Similarly, you can’t use _1 as a variable name — not that you’d want to anyway. Example:

_1 = "test"
# Yields: warning: `_1' is reserved for numbered parameter; consider another name

Focus on readability. Your fellow colleagues and future self will thank you.

Conclusion

May the above improve your code quality and make you a better engineer!