Ruby Best Practices

Ruby’s Other Secret Power: Code Blocks

In Ruby, code blocks are everywhere. If you’ve ever used Enumerable, you’ve worked with blocks. But what are they? Are they simply iterators, working to abstract away our need for the for loop? They certainly do a good job of that:

>> ["Blocks","are","really","neat"].map { |e| e.upcase }
=> ["BLOCKS", "ARE", "REALLY", "NEAT"]

But other blocks don’t really iterate over things—they just do helpful things for us. For example, they allow us to write something like:

File.open("foo.txt","w") { |f| f << "This is sexy" }

instead of forcing us to write this:

file = File.open("foo.txt","w")
file << "This is tedious"
file.close

So blocks are useful for iteration, and also useful for injecting some code between preprocessing and postprocessing operations in methods. But is that all they’re good for? Sticking with Ruby built-ins, we find that isn’t the case. Blocks can also shift our scope temporarily, giving us easier access to places we want to be:

"This is a string".instance_eval do
   "O hai, can has reverse? #{reverse}. kthxbye"
 end

 #=> "O hai, can has reverse? gnirts a si sihT. kthxbye"

But blocks aren’t necessarily limited to code that gets run right away and then disappears. They can also form templates for what to do down the line, springing to action when ready:

>> foo = Hash.new { |h,k| h[k] = [] }
=> {}
>> foo[:bar]
=> []
>> foo[:bar] << 1 << 2 << 3
=> [1, 2, 3]
>> foo[:baz]
=> []

So even if we label all methods that accept a block as iterators, we know ...