The ‘Poetry’ of Ruby

As a programming language, Ruby is often praised for its resemblance to a human language, English. This is a virtue particularly to those of us new to reading and writing in computer languages.

It is similarly praised for its flexibility. There is often more than one way to write a set of instructions. Consider this example that employs the .map method:

array.map do |num| 
  num * 2
end

Assuming the above array is an array of integers, this method will return a new array whose elements are the product of multiplying the original elements by two. The code block from “do” through “end” can be rewritten as:

array.map { |num| num * 2 }

For a simple method like the above, Ruby conventions would recommend using the braces over a “do…end” block. Generally, braces should be used for single-line blocks while “do…end” should be used for ones with multiple lines. It’s also generally preferred to use braces if you’re chaining methods, but Ruby still allows you to write:

array.map do |num|
  num * 2
end.sum

Options abound. Consider the built-in methods Ruby provides. Take, for example length and size. Both return the number of characters or elements in a string or array, respectively, and while there is some runtime advantages to using length, in practical use the difference is negligible. From reading numerous online posts on the topic, one convincing argument is to use length with strings and size with arrays, but this is mostly a matter of subjective preference.

Even on the small scale of hashes we are presented with choices:

{ :key => “value” }

…is the same as:

{ key: “value” }

If you have a simple if/else statement in a method, it can be written with a ternary operator.

if/else:

def greater_than_5 (n) 
  if n > 5
    "#{n} is greater than 5"
  else
    "#{n} is less than 5"
  end
end

ternary operator:

def greater_than_5 n 
  n > 5 ? "#{n} is greater than 5" : "#{n} is less than 5"
end

Notice I left out the parentheses surrounding the argument, “n”, in the method using the ternary operator. For the sake of readability, it may not be advisable to omit them, but Ruby still recognizes the “n” as an argument without parentheses.

For a large portion of my initial Ruby learning, I had assumed parentheses and brackets to be necessary grammatical components. It was when I began learning ActiveRecord that I realized that while I was still working with objects and methods, they could be presented in surprising ways.

Consider the methods you write in an ActiveRecord migration:

add_column :destinations, :img_url2, :string

Here, by convention, the parentheses are left out, but you could still write this as…

add_column(:destinations, :img_url2, :string)

… and it would be accepted. Ruby recognizes the arguments without parentheses. (Similarly, by following accepted orders of operations, we can evaluate a mathematical expression, 24 + 6 / 3 * 5 * 2³ – 9 without the need of parentheses to know which operations to perform first)

Similar formatting conventions are found when writing attribute accessor, reader and writer methods in ActiveRecord, and defining validations in Rails.

It was while learning the fundamentals of Rails that I was introduced to a Ruby idiom that describes this purposeful omission: Poetry Mode. I’m unable to find the origin of this term, but loosely it describes Ruby code written without parentheses or braces, examples of which I’ve demonstrated above. What, exactly, is ‘poetic’ about this syntax is debatable; regardless, I’m personally of the opinion that it generally decreases the average speed of comprehension. Maybe therein lies the comparison to poetry; immediate comprehension is no the point.

To an extant, there is always some tension between brevity and readability, between the desire to make your code concise and efficient, and the desire to make it easily comprehensible to other programmers (including your future self) who may have to work with it long after it was originally written. Personally, I’ve looked over code I wrote only a week or two earlier and wondered, “WTF was I trying to do here??”

From the perspective of the English language, there is an argument to be made that punctuation like parentheses and braces obscure the readability of code, but I find them to contribute to my comprehension. They are set of visual cues that tell me, immediately, to focus my attention. My mind more quickly parses…

24 + (6 * 5)

… than …

24 + 6 * 5