A general collection of ruby style guidelines that I tend to follow

style_guide.md

My Ruby Style Guide

General Syntax rules

Class names should be full camel-case:

class AtlasGuide
end

Method names should be underscored:

def some_method
end

Parenthesis in method definition and calls is discouraged, unless an expression will be interpreted incorrectly while passing args (or for chaining), or of course, if readability is at stake. Parameters need not be wrapped in parens for the definition. When providing a default for the parameter, don't put spaces around the '=' sign.

def run dry_run=false
	# ...
end

obj.run true
obj.run(true).results
obj.run(true) if obj.runnable?

Concise code rules when readability isn't sacrificed. This means using the {} syntax for blocks or using expression modifiers (if, unless, while, or until at the end of an expression) is encouraged.

array = [1,2,3]
array.each{|i| puts i}
array << 4 unless a.include? 4

Hashes should use the 1.9 syntax for key/value pairs when keys are symbols:

{a: 1, b: 2, c: 3}
obj.configure do_run: true, verbose: true

The exception to this rule is when writing gem code, since gems should be reusable by all parts of the system, including jruby projects.

Application lib files

Application source files that do not belong in the application's app/ directory should go in lib and should follow the standard convention for creating gems. This means that if you were writing a utils lib for your application, your source files would follow a structure similar to this:

|- lib/
	|- ...
	|- utils.rb
	|- utils/
		|- word_utils.rb
		|- protobuf_utils.rb
		|- protobuf_utils.rb
		|- other_utils.rb

The file at lib/utils.rb is simply a convenience file if you would like to have a single require line to get all of your utils code loaded at once:

require 'lib/utils'

As opposed to:

require 'lib/utils/word_utils'
require 'lib/utils/protobuf_utils'
require 'lib/utils/other_utils'

In this particular case, we would leave lib/utils.rb out since these are just utils and aren't interrelated. Ultimately, we don't want to pollute the top-level of lib with random source files. Everything should be foldered based on its usage.

Scripting

As noted below, the preferred scripting solution would be to use Thor instead of rake. Because rails has used rake so long, we can't completely get rid of it, but Thor's syntax is much cleaner and preferable to rake. Any Thor classes should be stored in tasks/:

|- tasks
	|- app.thor
	|- notifier.thor
	|- some_random_script.thor

Preferred Technologies to work with

• Ruby 1.9.2
• Rails 3 or Sinatra 1
• Bundler
• Thor for scripting (in place of rake where possible)
• Capistrano
• Rspec for Behavior Driven Development
• Cucumber for Feature Stories
• Haml for UI templating, utilizing partials
• Sass for stylesheet definitions (pre-compiled before code is released)