Hi --

On Mon, 27 Aug 2007, Esmail wrote:

> dblack / wobblini.net wrote:
>> Hi --
>> 
>> On Mon, 27 Aug 2007, Esmail wrote:
>> 
> <..>
>>> Comments? Please, I am not looking for an argument here.
>> 
>> The original question was how to make it more succinct, not more
>> elegant or transparent. As it happens, I don't think there's anything
>> particularly unclean or unreadable about the code above, though I've
>> pretty much given up on "readable" as a meaningful term. 
>
> :-)
>
>> Another point is that while Ruby certain does (in my view) provide
>> favorable conditions for writing nice-looking code, it's important not
>> to be *too* skittish about the use of constructs that can't always be
>> picked up at a glance. Some Ruby constructs are easier to read, and
>> for different people, than others. It was never part of the Ruby
>> contract, so to speak, that no one would have to make an effort to
>> learn how to read Ruby.
>
> Good points .. though in general I will favor "readability" (whatever
> that exactly means to everyone) over "cleverness" .. after all people
> end up reading/comprehending and possibly modifying the code, so it's
> good to help them as much as possible. Of course, as you say, this
> doesn't mean no effort should be made to know the language and its
> idiomatic expressions.

Readability is a tricky notion. I think it's most useful,
conceptually, at a pretty course-grained level. One can say that lots
of people have reacted to Ruby by finding that it is conducive to
writing readable code. That's just empirical. As soon as one starts to
get more fine-grained (such-and-such a code snippet is/isn't more
readable), the potential for disagreement rises rapidly and the
usefulness of the term starts to evaporate.

For example, people say that the /x modifier on regular expressions
make them more readable:

   /  (.)  ab  c?
               d?
      (\d)       /x

and all that. I find /x regexes very difficult to read and decipher
(even ones that are not parodies like mine :-)  That's just the way it
is. There's no point annointing any particular style (/x or non-/x) as
the "readable" one.

So it's hard even to know what will "help [maintainers] as much as
possible." This is part of why I'm so adamant about encouraging people
to stick to the traditional Ruby style, and not introduce a lot of
little idiosyncrasies just because the parser allows it. We're never
all going to agree about what's readable, and so on, but the
traditional style is what attracted most of us to Ruby in the first
place and it's as good a standard to rally around as any, and a lot
better than most.


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)