The code conventions of Rake

The words namespace, desc, task, touch, and so on in the Rakefile are general methods and, of course, you are able to pass parentheses when you pass the parameters there, as shown in the following code snippet:

namespace(:server) do
  desc('Restart web server')
  task(:restart) do
    touch('./tmp/restart.txt')
  end
end

However, the code looks quite ugly now, so it's recommended that you avoid using styles such as the one used here. Rake has its own DSL, and if you follow it, the code will be more readable.

The namespace and task methods are the basic methods that accept blocks that make the Rake code very expressive. For the task method, the block in the task definitions is optional, similar to what we saw in the Task dependencies – prerequisites section.

The blocks can be specified with either a do/end pair or with curly braces in Ruby. To specify a Rakefile, it's strongly recommended that you define rake tasks only with do/end. Because the Rakefile idiom tends to leave off parentheses on the tasks definitions, unusual ambiguities can arise when using curly braces. Take a look at the following proposed Rakefile:

def dependent_tasks
  [:task2, :task3]
end

task :task2 do
  puts 'In task2...'
end

task :task3 do
  puts 'In task3...'
end

task :task1 => dependent_tasks {
  puts 'In task1...' # We are expecting this code to be run but it's not
}

The following is the result of the execution of task1:

$ rake task1
In task2...
In task3...

The defined action in task1 is not evaluated. It leads to unexpected behavior. Because curly braces have a higher precedence than do/end, the block is associated with the dependent_tasks method rather than the task method.

A variant of passing the block after the dependent task name is not valid Ruby code at all, as shown:

require 'rake'
task :task1 => :task2 { }

It might seem strange but unfortunately, this code doesn't work and gives a syntax error as shown:

# => SyntaxError: syntax error, unexpected '{', expecting end-of-input

The conclusion of this is that if you just follow the Rakefile convention, you won't have problems with Rake's unexpected behavior.

Finally, the last tip for Rakefiles description: don't use the new style of a hash definition in the task prerequisites (in other words, don't describe tasks dependencies like this: task1: :task2). Often, only one prerequisite, defined at the first instance, transforms to the list of prerequisites and then you will have to translate the hash definition to the old style (in other words, the task1: :task2 code transforms to :task1 => [:task2, task3]). Usually, all the task definitions contain the hash rocket instead of the colon notation. The conclusion here is simple: use the old style of the creation of Ruby hashes in the rake tasks definitions.