How I snuck a super bad pun into our application

By Ben Golden on May 04, 2017

Two things I believe:

Software developers should occasionally sneak jokes into their code, to make life more fun, and to make sure the person reviewing their code is paying attention.
When reviewing code, jokes should usually be removed. Code should be clean, functional, secure, and efficient, and jokes don't advance any of these goals. Only the best jokes should survive code review.

With this in mind, let's take a look at a joke I just snuck into Cultivate Forecasts.

The Situation

Cultivate Forecasts gives administrators access to a range of reports on various user activity. These reports include a single row of column headers, and various data that correspond to the headers. Here's a partial example of our Forecast Report, which provides data on predictions that users made on a question:

id	prediction set id	question id	question name	answer id	answer name	membership id	membership username	forecasted probability
77	32	58	Will any Big Ten team make it through the basketball preseason undefeated?	141	Yes	6	superman5	0.75
78	33	58	Will any Big Ten team make it through the basketball preseason undefeated?	141	Yes	7	superman6	0.75

To generate reports, we have code that takes data from our database, creates a new .csv file, and formats and adds the data appropriately. So here's some code that adds report headers to a file:

def generate_headers(file)
  file.puts headers.to_csv
end

The code snippet above defines a method called generate_headers, which is used when generating each type of report. The headers are different for each report, but we always add them.

The Problem / Opportunity

We've been building new functionality that allows administrators to assign new users training materials (courses and surveys) before they start forecasting, and we created a Training Report to give insight into how users are progressing. However, we decided that for this report, in addition to the usual headers row, we wanted to add additional headers in the row above. If this row had been below our standard headers, I would have called them subheaders, but they're above, so I decided to call them superheaders. I created a method specific to Training Reports that overwrites generate_headers:

def generate_headers(file)
  file.puts super_headers.to_csv
  file.puts headers.to_csv
end

This presented an opportunity to simplify the code by using a Ruby method called super:

def generate_headers(file)
  file.puts super_headers.to_csv
  super
end

In this case, super just runs the original generate_headers method, appending headers to the file. This is a totally appropriate use of super, and of Ruby's inheritance property. And to my amusement, the method now uses the term super twice, both times appropriately, and neither time using its most common meaning (really good). Pretty super if you ask me!