Bill Guindon
4/8/2005 7:51:00 PM
On Apr 8, 2005 3:38 PM, Berger, Daniel <Daniel.Berger@qwest.com> wrote:
> > -----Original Message-----
> > From: Glenn Smith [mailto:glenn.ruby@gmail.com]
>
> <snip>
>
> > Today I was writing a long bit of code and the longer it got
> > the more worried that I was writing it incorrectly. That is,
> > it would be perfectly good style in the more
> > traditional-style languages I use - C, VB, PL/SQL etc. But
> > everything I've read about Ruby suggests short functions,
> > 'DRY', and an OO style.
>
> This is where TDD is your friend. It not only tests your code, it
> forces you to write methods that are easily testable. That usually
> prevents them from getting too long.
>
> > Below is an example of code I've written today. I'm not
> > asking anybody to debug it (I know it has a problem or two in there
> > somewhere) , solve problems, etc. What I'm wondering is, can
> > somebody glance at this code and say "yes you are writing
> > ruby in the correct form' or 'no, you should really
> > restructure this way or that way'.
> > It's just one (private) method cut from a Rails controller class.
>
> I dunno about structure, but you might want to consider whether or not
> change_sent or change_received should have default arguments (though
> this may mean reordering the args).
>
> Also, this line:
>
> if !defined?(activitydates['due']) or activitydates['due'].strip.length
> == 0
>
> Can be reduced to:
>
> if activitydates['due'].to_s.empty?
never thought to use '.to_s' to avoid the nil issue. Good to know.
see, I told you I wasn't a guru :)
> That's all I've got for now.
>
> Regards,
>
> Dan
>
>
--
Bill Guindon (aka aGorilla)