Hi folks,

I'm going to writing a short blog entry for the O'Reilly blog about
ruby conventions for project layout.  I think this is relatively
valuable, as it greatly simplifies the ability to audit projects and
possibly contribute to them.

(I've been researching a *lot* of different projects for various
things in Ruport lately)

I think I pretty much follow good practices when it comes to my
project organization, but I'd like to hear what people think and also
if they have anything to add.

Here are a few of the things I think are relevant:

== Structure ==

bin/  :  any scripts or executables

lib/   :  source files.

conventionally,

Ruport::Data::Table is in

lib/ruport/data/table.rb

alternatively, the class could be included in any file lower down the chain:
(e.g. lib/ruport.rb or lib/ruport/data.rb)

ext/ : C sources for extensions

doc/: documentation

test/:  All tests and test data.  Tests should begin with
test_class_name, however an older convention is tc_class_name with
ts_all.rb loading all your tests.

main directory:
Rakefile, main documentation files such as README

== Library requires ==

Do these in the correct logical places, so if you hav

lib/
  ruport.rb
  ruport/
   data.rb
   data/
       table.rb
       record.rb


Then ruport.rb should include:

require "ruport/data"

and data.rb should include:

require "ruport/data/table"
require "ruport/data/record"

There are of course exceptions to this...

== Tests ==

One test per method, ideally, mapping method name to test.
Additional tests for bug reports, edge cases, etc.
( I usually use a name like test_ensure_table_append_accepts_arrays)

or some really long name describing the problem I'm checking for

== Organization of methods in source / tests ==

This i'm not sure about.  Some people do alphabetical, some do
alphabetical by concept, some do just concept, some no organization.
I think that it is helpful when the tests follow in the same order of
the source, though.

What do people think about this.

== Other things? ==

I am aiming for something short and simple.  I don't want to overwhelm
people with a ton of rules to follow, but a few basic conventions for
those who haven't really looked into other projects yet would be
helpful for all of us, I think.

However, if anyone thinks they've got some really important tips to
share, let me know.