On Dec 13, 2008, at 2:11 AM, David A. Black wrote:
It can serve a purpose, but please have mercy on those of us who like
our Ruby in order It’s really not that hard to get used to the
principle that the code (including method definitions) is executed as
it’s encountered, and then you don’t have to think about whether or
not to flip it.
i like it in order too - logical order that is:
has_many :children do
the reality is that logical order and organization is far more
important, consider reading a rails app ‘in order’ or having to
install your own ‘run’ hook at the end of every test suite. the
reality is that it’s situational - if a script has 50 methods before
it gets around to the ‘main’ call any sane person might enjoy reading
the ‘help’ method first. this is an overriding principle of my
‘main.rb’ lib and i think most people would agree that reading
is preferable than needing to dig through the source until the help
method happens to come along. same goes for associations in models
and filters in controllers, etc. also consider that a block in ruby
may or may not be executed in the same order that you read it
good thing this doesn’t run here
or the fact that helper methods aren’t injected into a view in rails
until very late in the execution phase and are silo’d off precisely so
that we do NOT have to read them en route to understanding a view.
the order of code is always situational but i think that people who
read alot of code from many languages, not only ruby, will agree that
logical order is the one thing that should always be considered,
language limitations/conventions are always a secondary consideration
unless one programs exclusively in one language. i think this is
actually quite important since the evolution of ruby will introduce
compliers and other enhancements that will/are undoubtedly change the
way code is evaluated while logical constructs will remain stable.
so my thinking is that rubyists should always strive to present code
in a rough logical order so long as great deviations from the idioms
of the language are not made. this included organizing projects into
a good hierarchy, factoring out libs, using deferred execution
(lambda), and tools such as BEGIN|END|at_exit etc. by using all the
tools provided to support the cleanest logical presentation code
reading will be enhanced for even those without vast rubyfu.
my 2 cts.
a @ http://codeforpeople.com/