Question on the "common way" to code

rubyonrails-talk
1

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?

2

(1) It depends. The first allows the database to do the sorting,
which is almost always a good thing. The second performs the sorting
in memory, and is thus likely to be slower. I've seldom seen the
second method employed in real code because databases are so good at
sorting.

(2) In RHTML, many people use <% for composer in @composers -%> I
don't. I don't use for in Ruby. So my looping code is usually <%
@composers.each do |composer| -%>. That said, it is often cleaner to
render collections in partials. That would look like this: <%=
render :partiai => 'composer', :collection => @composers %>.

(3) Whatever works. Either works fine, both are ugly but necessary.
Better, in your model do this:

def full_name    first_name + last_name end

Then in your view, you can just write:

<%= link_to composer.full_name, composers_url(composer) %>

Just some thoughts.

3

s.ross wrote:

(3) Whatever works. Either works fine, both are ugly but necessary. Better, in your model do this:

def full_name    first_name + last_name end

The question was ".." vs. model.method + " " + model.method. I agree you should put these kinds of function in the model or in a helper.

3. dynamic links link_to(composer.first_name + " " + composer.last_name and link_to("#{composer.first_name} #{composer.last_name}"

Personally I usually prefer the second alternative as I find it easier to read. But that's just a matter of taste.

4

Hi --

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 :slight_smile: But I would certain do things like this:

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

David

5

Hi --

(3) Whatever works. Either works fine, both are ugly but necessary. Better, in your model do this:

def full_name   first_name + last_name end

Then in your view, you can just write:

<%= link_to composer.full_name, composers_url(composer) %>

That still leaves the question of how to define full_name (with + or with string interpolation), though. Some informal benchmarking suggests, not too surprisingly, that if you're adding just two strings, the adding might be faster, but if you're adding repeatedly:

   title + " " + first_name + middle_name + last_name

then there's a tipping point at which interpolation is faster.

David