Brian F. Feldman replied:

> You think so?  My eyes, when following it, are drawn to the 
> periods and the matching parentheses/braces/brackets. 
> In other words, my ... style? ... will often include more 
> punctuation whereas yours will include whitespace because 
> that's what really helps you visually pick out control flow.

I guess they have some studies about these things, so it would be
interesting to know scientific truths behind :). I think your observation is
essentially the difference between us. I read much easier whitespace
delimited text. I guess I could get used to punctuation style, but I think
Perl is better with syntax-highlight (giving me the non-punctuation based
hints of the flow) than without. And that in other languages it doesn't
matter as much.

> Also, I notice that I tend to give ephemeral arguments 
> one-letter names. How shell-scripty!

I used them a lot too. Nowadays I find it much better to have "meaninful"
names, but most of all it's about being consistent. So it doesn't matter too
much in simple case like this

>         subber = lambda {|s|

if you have s, str or string, as long you do it in a same way in other parts
of the program also. But if you happen to pass occassionally a Struct to
your blocks with short names there's better to be some difference between s
and s.

There's another reason too. 's' doesn't tell much more than string. Many
times the string is a special field or something else. Thus the name
shouldn't be 'string'. It should be more like 'sql_property'. Probably not
in this case, but in general.

> I'm one of those people that believe that if you're only 
> using something once, it's usually wrong to give it a 
> name unless otherwise it would truly make things very 
> hard to follow.

That's a nice principle to follow. Is there any more explicit versions of
this around? Describing like when exactly you're using some thing only once?

  subber = lambda {|s| s.succ}      # once?
  subber = lambda {|s| s + s}       # twice?

> In this specific case, I usually /try/ to 
> let my regexps speak for themselves.  If they're so hard to 
> follow that I can't tell what they're for, they're probably 
> not very good at all :)

I understand. I did that too. Then I had a season that I made all the
regexps in commentary mode. Nowadays I prefer just to name them (and maybe
give a comment if needed). There are couple of regexps that don't need
comment or name IMO, like /s+/ and such simple, and short ones. I guess I
tend to write too hard regexps still, without naming them elsewhere.

The major thing is, that the regexp could be easy to read to it's author,
but quite horrible for the others. So I try to give a reason for myself to
code verbosely (and nicely) using other people as an excuse ;).

> > Still I'd like to exploit the possible rule of "unsub every second
> > parameter", name the mystical range of 1..-2, give better names to
> > variables in unsubber, maybe split the long line of listed_numbers
> > definition into two lines and call collect! on the latter.
> 
> I don't think that's a very good rule, because it's really just... 
> coincidental:

Yep, I guessed the rule wasn't real this time, just looked like it,
therefore the word "possible".

> The range 1..-2 will probably be seen an awful lot as the 
> most common idiom for taking the "inside" of a string.
> I can't think of any way to express it better :)  

Indeed, that will probably happen. But it will be pretty tricky for the guy
not messed with strings. You have to "see" what the data looks like when you
try to decipher the meaning. Some people, like me, aren't good at imaging
the underlying data, so I had to go in and see it in debugger or by other
means. Writing code in a way which makes it more apparent helps
tremendously, mostly removing the need for runtime inspection.

In this case, I'd consider changing string class

  class String
    def inside    # drop the first and last character of the string
      self[1..-2]
    end
  end

or the same as a (named) helper method

  def inside(str)
    str[1..-2]
  end

then the client code would be like

  inside(e[0]).gsub(/\\(.)/, '\1')

> > Do we still disagree ?)
> 
> It's a matter of style :)  

Definitely.

> I feel you raise a lot of good points, but I find my 
> ethos on it to be different from yours.  So, I agree to 
> disagree on parts of it, but I agree with you when you 
> suggest that making things more "documentary" is 
> useful.  Perhaps I should use comments some time...

Agreed. :)

> P.S.: I just noticed that using Ruby for this kind of stuff 
> rather than C, saying nothing about the amount of code 
> needed, I never need any comments in the Ruby code to 
> go back and understand any of it, but for C I always need 
> to comment all manner of uncomplicated code.

I find the same to be true. I wonder what the reason might be but maybe it's
just that I'm more accustomed to code in a documentary way in Ruby than in
C. Go figure out.

	- Aleksi