Re: Question on the "common way" to code

dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org
Sun, 22 Jul 2007 10:14:31 -0000

Hi --

On Sat, 21 Jul 2007, nemesis256 wrote:

>
> So I posted last week asking about new learning resources.  I watched
> the lynda.com RoR videos, and now I just started reading the Ruby for
> Rails book.  Both of these sources code in different ways, and I was
> wondering which way is most common.  In other words, is one of these
> ways frowned upon in the Rails community?  Keep in mind that these are
> rather specific examples and not necessarily complete lines of code.
>
> 1. First is how things are read from a database, or more specifically,
> sorting.  One does this
> @albums = Album.find(:all, :order => "title ASC")
> while the other does this
> @composers = Composer.find(:all).sort_by{|c| [c.last_name,
> c.first_name]}
>
> 2. Looping.
> <% for composer in @composers -%>
> and
> @composers.each do |composer|
>
> 3. dynamic links
> link_to(composer.first_name + " " + composer.last_name
> and
> link_to("#{composer.first_name} #{composer.last_name}"
>
> In all cases I prefer the first (lynda.com) method, either because
> it''s shorter or because it requires less symbols.  The Ruby for
Rails
> method seems to be a lot more object focused.  So which of these do
> you see more often or is the common way?  Or does it not matter?

Going from bottom to top:

Using string interpolation is slightly more efficient because it
avoids creating a lot of intermediate string objects.

"each" is generally considered more idiomatic Ruby than
"for".  for is
really just sugar-coating for each:

   irb(main):018:0> for a in nil; end
   NoMethodError: undefined method `each'' for nil:NilClass
                                    ^^^^

Queries are a little more complicated.  There are, as you point out,
examples in my book where you could use :order (and probably other
things) -- and I certainly wouldn''t argue against it, though
I''ve also
seen people devote a lot of development time to fine-tuning big SQL
statements when a bit of Ruby would have done the same thing, even if
at some point down the road it ended up getting optimized into SQL.
So you can be creative about what role(s) you want the Ruby techniques
to play (or not play).

One rule of thumb that I try to follow is never to take out too many
records, just for the sake of making it easy to manipulate them in
Ruby.  So, for example, I''d avoid this:

   Item.find(:all).select {|i| i.number < 100 }

since that''s liable to pull out some huge number of records and then
throw most of them away.  (I can''t remember if there are examples like
that in my book... but never mind :-)  But I would certain do things
like this:

   Item.find(:all, :conditions => "number < 100").sort_by
{|item|
     item.description.sub(/^(a|the) /i, "")
   }


David

--
* Books:
   RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
   RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
     & consulting:  Ruby Power and Light, LLC (http://www.rubypal.com)