On Feb 18, 2009, at 6:30 PM, James Britt wrote:

> Florian Gilcher wrote:
>> On Feb 17, 2009, at 9:30 PM, James Britt wrote:
>>> David Masover wrote:
>>> Same here.  I think of them as FGPs: Feel-good parentheses, used  
>>> because they make people accustomed to C or Java feel more  
>>> comfortable, though they do not contribute any real code value.
>> Thats a harsh statement for those that do actually like parantheses  
>> and not because they are C//Java-Guys.
>
> I'm sure there are people who did not come to Ruby after using Java  
> or C and still think the parens make the code easier to work with.   
> I just haven't met them. :)

Meet: me. No Java//C-Exposure beyond the absolute must in university  
courses (and I learned Ruby before them). And as I said before, it's  
highly depending on the context.

>
>> For example, i find the following irritating and bad style:
>> ===
>> def initialize foo, bar, batz = {}, &block
>> #(vs.)
>> def initialize( foo, bar, batz = {}, &block )
>> ===
>> I see the argument list as a tuple and I like it to resemble one.
>
> Except you can't do this:
>
> def foo  (my, tuple, arg); end

Sure, it is not a perfect image. It's just the direction.

>
>
> There *are* times when the parens may make the arg list more  
> readable, but it ends up being a matter of taste, and that comes  
> from exposure.

I'm a fan of consistency. Even in relativly strict defined languages  
like Java and C I always shriek when seeing people using several  
styles just as they see fit. Obviously, making them mandantory (and  
them omittable in some very special cases...) doesn't fix the problem  
as well.

As you said: there are moments where parens help ("def a b,c = {}"  
being a good example). So, I prefer to stick to them in all parameter  
lists to eliminate this question. Especially because I have a tendency  
for creative use of parameter lists (that make Java guys shriek).

Rest assured, I am writing:

===
div.address "bla", :class => bar do
  #something different
end
===

when using Builder//Markaby (for example), because parens would  
clutter the declaration.

The thing is that I try not to mix the styles. As I said, I clearly  
prefer:

===
foo(bar(batz))
# over
foo bar(batz) # looks unbalanced
===

To extend this:

===
some_method bar(batz)
some_other_method bar # oh
===

Suddently, the braces really hurt. While in a balanced display  
(granted, it's hard to conjure up nice examples):

===
some_method(bar(batz))
some_other_method(bar)
===

So, I prefer to just stick to the braces.

> The more people add the redundant parens, the more they see it as  
> "right", and the more they do it.

That sounds like they are utterly wrong.

> I prefer to omit whatever I can until I have a good reason not to.  
> Maybe that good reason ends up being, "I'm making more stupid  
> errors", and that's fine, but so far I've had fewer such errors  
> without the parens than with them.

I don't to parens errors as well... so? I think the difference is  
neglectible.

> I don't expect anyone is going to change their minds on this based  
> on words alone, but it's interesting to see how preferences evolve.
>
> For example, in learning Haskell, I've come across a number of  
> places that explain that while one can use parens in various places,  
> the preferred style is to leave them out when possible.  Different  
> culture.

Not only a different culture but also different facilities. Haskell is  
far better in grasping things like "foo bar batz a" (oh, didn't write  
Haskell for at least 2 years... is that valid?).

At the end of the day, it is the projects maintainers call how the  
code should be written.
Maybe it might be worthwhile to document those styles at a certain  
place for maintainers to refer to "their" style.

And, thats why I tuned in: attributing brace styles other then Your  
Enlightened One to other persons inability to find The True Way. There  
is a language called Python for that ;).

Regards,
Florian Gilcher

--
Florian Gilcher

smtp:   flo / andersground.net
jabber: Skade / jabber.ccc.de
gpg:    533148E2