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)