FWIW, I prefer to use an indent of one when the normal indent is two for a block

def foo
  bar
 rescue
  baz
 ensure
  quux
end

There are some fuzzy reasons for this (such as "a rescue clause is not on the same level as normal code and can be added later") which are pretty arguable, so YMMV, but I think something should be present anyway

I wonder if there is consensus on how/when to use single line method definitions. E.g.

  def foo() bar end
  vs
  def foo; bar; end

It's a small thing, and I'd say it makes sense to point out that usually it's just better to avoi them. Although I write them all the time :)

I disagree with a couple of things in the extensions page.

Firstly, I feel that crossing out the word "monkeypatch" and having "hack" as a crossed-out term also makes the document a little personal. This should be an educational document and any personal vendettas you have against this coding style should be explained in a neutral tone with clear examples of why it is bad or when it is bad. Sometimes it's a Necessary Evil.

Secondly, I view this line as a hack:

Dir[File.expand_path("../../../lib/extruby/**/*.rb", __FILE__)].each { |f| require f }

Honestly, I was going to suggest adding the lib/extruby dir to the autoload_paths for the application (in config/application.rb) but that wouldn't work, as many of the constants you are "extending" are already loaded, and so it will not attempt to autoload them.

Anyway, I would rather this be put here:

Dir[Rails.root + "lib/extruby/**/*.rb"].each { |f| require f }

This is much cleaner (no relative paths) and reads much better.

Thirdly, you should be more explicit in this sentence for point #2 of your "Considerations" sub-section:

It prefixes the initializer with _ causing the initializer to be loaded before any initializer, making the extensions available as soon as possible.

It will not be loaded before any initializer, because if I had an initializer called _do_something.rb that initializer would be run first! You should write that initializers are run in alphabetical ordering and by prefixing this initializer with an underscore we make it run first.

There should probably be some notes about how to handle exceptions, of the top of my mind

• only use inline rescue to provide a default value, or nexting during iteration

  ary.map {|x| x.foo_bar rescue ... } #good
  ary.select {|x| x.foo_bar rescue next } #good
  do_something(...) rescue do_something_else(...) #bad

• do not rescue Exception unless you really mean it

• (arguable) do not create unnecessary exception objects (rescue => e)

• if possible be strict in what you mean to catch (rescue SubSubCustomEx vs rescue Exception)

• prefer shorthand syntax for rescue/ensure within methods. Write small methods so you don't overcatch stuff

  def foo() #good
  ...
  rescue
  ...
  ensure
  ...
  end
  def foo() #bad
  begin
  ...
  rescue
  ...
  ensure
  ...
  end
  end

• do not swallow exceptions, or at least always log both error message and backtrace (although you may want to log them at an info level if they are "expected", e.g. network errors in a crawler)

• if possible use techniques that can avoid you causing exceptions altogether, mostly NME comes to mind:
  ** respond_to? **try **Hash.new` with defaults

I realized these are missing, both as editor conventions (e.g., if base indent is 2, indent "private" keyword by 1 is what I use) and coding style. Off the top of my head

• should we use _foo for private methods ? I always thought it makes sense (way more then private does in ruby), but I seldom see it used

• should we use private/protected methods at all?

• when should we use private with or without arguments?

  private
  def foo()... end;

  def foo.... end
  private :foo