I agree with the points Greg makes about variable naming.
I place in a slightly different context though:
A basic premise is that source code read many more times than it is written.
Therefore readability (meaningful, describing constructs) is more important
than
convenience and speed of writing (that is short names) or even concise
constructs (such as certain idioms, likea||=b).
IMHO Ruby does a good job with ! and ? at the end of method names and Rails
does
a good job of pluralization. However, one language that stands out as easy to
read is Smalltalk (and derivatives such as Objective-C) because of the explicit
naming of parameters. Just think how much easier life would be if the IDE
understood what parameters could be passed: form_for(@user, :url =>
'post_email', :html => { :method => :post } ).
Just my $0.02 worth,
--Allan
----- Original Message ----
> From: gw <[email protected]>
> To: SD Ruby <[email protected]>
> Sent: Fri, May 6, 2011 11:25:06 AM
> Subject: [SDRuby] Re: Quick Code Assessment
>
> On May 6, 2011, at 10:29 AM, Eitan wrote:
...
>
> I see this as good an opportunity as any to discuss variable names
> (sorry if this turns into a hijacking of the thread, but maybe the
> feedback will tell Eitan whether this is an important detail for him
> to consider).
>
> Personally, I cringe when I see cryptic variables like:
>
> u.login and u.reset_token # in business_users.rb
> u = Admin.authenticate(...) # in admins.rb
> bus_user = valid_bus_user_token?(...) # in app_subscriptions.rb
>
> So, let's start with the variable u. OK, so maybe since it is in a
> file named "users" I am supposed to show I am not a moron and just
> recognize that u is a user. My problem is that when I read code in my
> head and am constantly saying "ok, then yooo login and yooo reset
> token" makes no sense to me. I have to mentally stop and substitute
> the word user. This takes mental energy and slows me down. Also if u
> gets used somewhere else in the app, does it mean user or something
> else? If the programmer would not have been so lazy (yes I feel that
> strongly about it), then reading this code would be much easier and
> working with it would be more productive. Additionally, when I now
> modify or extend this code, I have to remember which little
> abbreviations were used, which I find harder to do that remember which
> full word was used.
>
> A worse example: bus_user. So this is a transportation application
> where we're managing bus users? Not drivers but users? Obviously
> context will cure that question, and that diversion only lasts a
> minute or so. Again, though, the problem is that reading that code I
> am saying in my head a "bus user does this and a bus user does that."
> It creates mental images that are counter productive.
...
>
> -- greg willits
...
--
SD Ruby mailing list
[email protected]
http://groups.google.com/group/sdruby
