Kevin Smith commented Dave Thomas' text:

> >There's another style I;ve seen her which I'm still thinking
> >about. Some folks put the block parameters on their own line:
> >
> >   a.doit {
> >     | name, address |
> >     # ...
> >   }
> >
> >It certainly looks nice, but I can't quite convince myself there's a
> >reason to do it ;-)
> 
> And there's your reason. "Looks nice" is a good 
> thing.

I'm quite sure that we're talking about different emphasis people put to
their code, and we shall end up with "got used to this way of coding"
argumentation, but I'm willing to say couple of more thoughts.

For me the above doesn't look nice, nor better than version where parameters
are on the same row:

  a.doit do |name, address|
    # ...
  end

And I guess most of the people (at least language designers) think in a same
way. If you think how K&R C was written with function definition and
parameters on one line and parameter types on the following lines and
compare that to ANSI C with one line definition you get the idea pretty
quickly. Both are doable, both are readable, but most people find the ANSI
way easier to read and write, and somehow better.

Which reminds me of my early Ruby code. I was so new to the whole block
thinking that I had to use braces (like in Perl) and there was no way to
sort out what was going unless I put the parameters on their own line.
Nowadays it's more cumbersome to split the definition to multiple rows,
which I'd like to do if the definition becomes too long.

Mathieu Bouchard wrote:
> >The lack of spaces emphasises that those elements are all 
> >part of the same chunk as the open brace.

I have about the same idea.

> I use whitespace to make code 
> easier to read, and I just find that putting the 
> | var | on its own line: a) reduces clutter on 
> the do line which is often long already, and b) 
> puts it in a consistent place where I can always 
> find it easily.

I like whitespace for the same reason. But not too much of it. But better
too much than too little.

I agree of your a) case, but would like to comment that it's often better to
make the line shorter than move the definition (it's not possible always).
And the reasoning for the b) case is fine and clear. But for me the
consistent place is right after beginning of the block. Not allowing
expections for the rule, is like requiring that |variable, list| can't ever
be longer than one line.

For me the fact that I have to read two lines just to get the basic idea of
what the block is doing (which object == receiver, does what == method, by
what objects == parameters) is not too much, but too much if one line does
the same.

> Back to the { } vs. do/end question: Although 
> I've considered using { } for single-line blocks, 
> I've decided that { } in Ruby is reserved for 
> hashes. I think I'll use do/end for all blocks, 
> to avoid that ambiguity.

Even though I follow the principle we're been talking about, I have
considered your way too. But I have the opposing reason not to use do..end
for all blocks also:

  list.collect do |element|
    element.tricky_calculation
  end.this_is_not_nice

I can read and accept {..}.with_chaining easily but do..end.with_chaining
doesn't look nice. I've tried to add some whitespace but I can't say it
helps in this case.

	- Aleksi