From: Giles Bowkett <gilesb@...>
Date: 2006-04-08T01:44:15+09:00
Subject: Re: best practices

On 4/5/06, Ryan Bates <rbates@artbeats.com> wrote:
> On Apr 5, 2006, at 2:40 PM, Benjohn Barnes wrote:
> > :) I choose the third way. I find the first approach too long, and
> > I dislike unnecessary intermediate values of the second.
> >
> > My approach is to factor out the computation of duration in to a
> > separate method:
> >       def duration; mins.to_s * 60 + secs.to_i; end
> >
> > Allowing me to write the call as:
> >       songs.append(Song.new(title, name, duration))
> >
> > I find this helps to make code highly self documenting in many cases.
>
> I prefer that method as well. IIRC, Martin Fowler also recommends
> this (reducing the number of variables) in his Refactoring book. This
> may cause performance loss, but optimize later when you know it's a
> problem; and don't let it keep you from making pretty code.
>
> There are always exceptions of course, and I think it may be a little
> over-kill for the simple example, but use your own judgement.

Thanks for pointing this out. Until I read "Refactoring," I used to be
a big fan of the temp variables approach (in Perl, I'm new to Ruby)
because it is really much easier to read, but it also has a sort of
temptation for the maintenance programmer lurking there. There's this
handy little variable floating around which could be used to store
pretty much anything. If you use a method rather than a temp var, you
still get all the self-documenting stuff, but in a format that's a lot
less susceptible to misuse.

--
Giles Bowkett
www.gilesgoatboy.org