Why does a lot of code not include parenthesis?

[egervari]

I just started playing around with ruby and rails, and one thing I've
noticed is that the style of the code is a little odd. People don't
use parenthesis most or even all of the time.

I find this to look messy. It's hard to tell what is the method, what
is the variable, and how the code is formed at a glance. I actually
find the parenthesis to be more readable. There is no confusion at all
to what is going on, even if it's a bit more to type.

Is there any reason tastes in style have changed? I think it would be
best to stick with the parenthesis just to make everything consistent.
It should be easier to refactor code and inline things if the
parenthesis were already there after all.

Thoughts?

 

[egervari]

I just started playing around with ruby and rails, and one thing I've
noticed is that the style of the code is a little odd. People don't
use parenthesis most or even all of the time.

I find this to look messy. It's hard to tell what is the method, what
is the variable, and how the code is formed at a glance. I actually
find the parenthesis to be more readable. There is no confusion at all
to what is going on, even if it's a bit more to type.

Is there any reason tastes in style have changed? I think it would be
best to stick with the parenthesis just to make everything consistent.
It should be easier to refactor code and inline things if the
parenthesis were already there after all.

Thoughts?

Oh, another reason I like using . and () is because IDE support is
there. If you use spaces, you don't have the IDE give you all the
options to save on typing. This alone is a big win. And you still get
better readability after the fact.

 

[Rajinder Yadav]

I just started playing around with ruby and rails, and one thing I've
noticed is that the style of the code is a little odd. People don't
use parenthesis most or even all of the time.

I find this to look messy. It's hard to tell what is the method, what
is the variable, and how the code is formed at a glance. I actually
find the parenthesis to be more readable. There is no confusion at all
to what is going on, even if it's a bit more to type.

Is there any reason tastes in style have changed? I think it would be
best to stick with the parenthesis just to make everything consistent.
It should be easier to refactor code and inline things if the
parenthesis were already there after all.

Thoughts?

its a personal style, for most simple calls parenthesis are left out. i
personally like to use them. after a while you get use to reading code
with them missing. don't let it worry you too much!

 

[David Masover]

Oh, another reason I like using . and () is because IDE support is
there. If you use spaces, you don't have the IDE give you all the
options to save on typing.

Get a better IDE, or learn to work without one. Seriously, it's pretty
unambiguous that a method call and a space means either an argument list or a
block is coming next, right?

 

[David Masover]

I just started playing around with ruby and rails, and one thing I've
noticed is that the style of the code is a little odd. People don't
use parenthesis most or even all of the time.
Right.

I find this to look messy.

I find redundant crap looks messy. Without parentheses, it can often read like
English, and it's very easy to build remarkable DSLs.

It's hard to tell what is the method, what
is the variable, and how the code is formed at a glance.

I don't agree, but maybe I've been looking at it for too long. Maybe it just
takes practice. However, I think it's much more important whether I can tell
what a piece of code is trying to do -- it may be slightly more difficult, but
I can always figure out how it works.

Is there any reason tastes in style have changed? I think it would be
best to stick with the parenthesis just to make everything consistent.

With what?

I am consistent. I don't use parentheses unless I have to. This is true even
in languages where parentheses are required for method calls. Consider:

distance = Math.sqrt(x*x + y*y)

Yes, I had to write parens around the body of the square root to make it
unambiguous. Were this Java, I would also be required to because Math.sqrt is
a method call. But I didn't do this, though I could have:

distance = (Math.sqrt((x*x) + (y*y)))

I don't know about you, but I find that a lot less readable.

I'm also consistent with the majority of the Ruby community, so about all
adding parens would help with is being consistent with other programming
languages -- but I think we should celebrate Ruby's strengths, not try to
bring it down to the lowest common denominator.

I'm also consistent with how you run commands. After all, you don't do this:

'gem' 'install' 'rails'

...do you? Single-quotes would be unambiguous, and it would make your commands
more consistent with the times when you actually need them to escape special
characters, like spaces:

rm 'My Essay.odt'

But even though it's only a few extra keystrokes, I think most of us would
find the extra noise to be _less_ readable, not more. Quoting, in this case,
is a tool to remove ambiguity, nothing more -- and I would argue parens serve
the same purpose in most languages, and should not be required when the
meaning is unambiguous.

Same with semicolons. You can put them at every line, but Ruby is smart enough
to figure out what you mean most of the time, so instead, you only need to use
semicolons (or a backslash at the end of a line) as an exception to the rule,
as a tool to remove ambiguity.

It should be easier to refactor code and inline things if the
parenthesis were already there after all.

How so?

 

[Scott Gonyea]

For starters - http://en.wikipedia.org/wiki/TMTOWTDI

Second, ruby is very beautiful code. It's a tad bit of a mind fsck at =
first, which is a good thing. Programming languages are only valuable =
if they teach you how to think in different ways.

Yes, the lack of parenthesis are irritating at first. If you stick with =
Ruby, and really dig in, you'll begin to get used to it. More =
important, you'll develop an opinion on how syntax *should* be. For me, =
I'm exceptionally pedantic on the following:

- Declaring a method: Always use parenthesis
- Calling a method: Don't use parenthesis unless you're trying to do =
something complicated (s/complicated/stupid/)
- ie,
# define
def pow(num1, num2)
num1 ** num2
end
# call
pow 10, 2
- also: if you use a single-letter variable name, I will kill you in =
your sleep

I'm also a sticker on return statements. Ruby will return the last =
value in a method. That said, if your method is not simple, I'm very =
big on making sure everything is explicit. Also, I'm big on using =
parenthesis in a return statement.
return(num1 ** num2) # ahhh

In conclusion, you really won't find a gofmt.com edition for Ruby. It'd =
be more of a gofys.com. TMTOWTDI means a bit of freedom and, therefore, =
disagreement. I think that's a very healthy thing, albeit =
rage-inspiring at times.

If you really can't handle it, Python was invented by some guy who =
clearly had to spend his internship days maintaining someone else's Perl =
code...

Scott

 

[egervari]

In the case of the sqrt line, those parenthesis are not required, and
you're right - they are less readable.

But take for example this line:

y = 10.div 10.div 5

This is valid code. It produces the result "5". To me, this looks
really bad though. Believe it or not, I can infer exactly what it's
doing much easier by writing it this way:

y = 10.div(10.div(5))

The order is very clear.

See, in Scala, you don't need the "." when you drop the parenthesis,
so dropping them both turns out to be much nicer and clearer:

val y = 10 div (10 div 5)

To me, that actually looks very nice indeed (let's assume div is also
a method on Int in Scala). Of course, dropping all the parenthesis
would change the result to .2 (or 0 I guess).

I just think this mandatory "." without the parenthesis looks weird
and is unintuitive. I think it's better to drop both, or to have both.
The middle-of-the-road syntax that includes the "." just looks bad.

Of course, once one gets used to it, I guess it'll become readable.
Just not the most intuitive, that's all.

 

[Rajinder Yadav]

If you really can't handle it, Python was invented by some guy who clearly had to spend his internship days maintaining someone else's Perl code...

Scott

good one!

 

[steve ross]

In the case of the sqrt line, those parenthesis are not required, and
you're right - they are less readable.
=20
But take for example this line:
=20
y =3D 10.div 10.div 5
=20
This is valid code. It produces the result "5". To me, this looks
really bad though. Believe it or not, I can infer exactly what it's
doing much easier by writing it this way:
=20
y =3D 10.div(10.div(5))
=20
The order is very clear.
=20
See, in Scala, you don't need the "." when you drop the parenthesis,
so dropping them both turns out to be much nicer and clearer:
=20
val y =3D 10 div (10 div 5)

Is it really productive to compare the use of punctuators in Ruby with =
that of Scala? If you read Scala better, use it. If you see value in how =
Ruby programs read, fine, use Ruby. I wouldn't expect Ruby's syntax or =
idioms to change dramatically in response to how you visually parse =
Scala. I would, similarly, not expect much ground to be given to work =
with lazy IDEs that don't correctly parse Ruby code.=20

 

[Phillip Gawlowski]

In the case of the sqrt line, those parenthesis are not required, and
you're right - they are less readable.

But take for example this line:

=A0 =A0y =3D 10.div 10.div 5

This is valid code. It produces the result "5". To me, this looks
really bad though. Believe it or not, I can infer exactly what it's
doing much easier by writing it this way:

=A0 =A0y =3D 10.div(10.div(5))

The order is very clear.

And the Ruby parser should actually warn you about the ambiguity. The
key to understanding when and why Rubyists (usually) use or not use
parentheses is knowing that they are dropped when they are *optional*,
and when it is, well, to taste.

Same thing with block syntax. Whether to chose do...end or {...} is a
matter of taste, and what feels "right" in the circumstances.

See, in Scala, you don't need the "." when you drop the parenthesis,
so dropping them both turns out to be much nicer and clearer:

=A0 =A0val y =3D 10 div (10 div 5)

This isn't clear to me. Is div called on the 10, or the 5 (or on the
10 and the result of 10 div 5)? The result would be different. But I'm
pretty sure that you now consider me a particular brand of
unenlightened. But that is because I'm not familiar with Scala, nor on
what the Scala community settled on as best practices for writing
code.

To me, that actually looks very nice indeed (let's assume div is also
a method on Int in Scala). Of course, dropping all the parenthesis
would change the result to .2 (or 0 I guess).

I just think this mandatory "." without the parenthesis looks weird
and is unintuitive. I think it's better to drop both, or to have both.
The middle-of-the-road syntax that includes the "." just looks bad.

That's more a matter of being used to it, than it being "bad" or
"good". object.method makes it obvious that you are calling the
#method
on the Object, and anything that follows is a parameter you pass into #meth=
od.

Of course, once one gets used to it, I guess it'll become readable.

Absolutely. A seasoned Perl vet will consider Perl code very readable,
too, after all.

Just not the most intuitive, that's all.

This has more to do with where you came from (IIRC, the object.method
notation is being used pretty much everywhere, from .NET, to Java, to
Ruby), and what you are used to, than actual intuitiveness.


Of course, nobody can tell you not to use parentheses when you want
to, and to use {...} when you want to, or to create a DSL for yourself
where you can use "10 div 5" as valid syntax in Ruby.

--=20
Phillip Gawlowski

Though the folk I have met,
(Ah, how soon!) they forget
When I've moved on to some other place,
There may be one or two,
When I've played and passed through,
Who'll remember my song or my face.

 

[Josh Cheek]

[Note: parts of this message were removed to make it a legal post.]

- Declaring a method: Always use parenthesis

Same, though there are some prominent people who disagree (Aaron Patterson).
I feel lost without them, though.

I'm also a sticker on return statements. Ruby will return the last value
in a method. That said, if your method is not simple, I'm very big on
making sure everything is explicit. Also, I'm big on using parenthesis in a
return statement.
return(num1 ** num2) # ahhh

Not even C or Java make you do that.

In the case of the sqrt line, those parenthesis are not required, and
you're right - they are less readable.

But take for example this line:

y = 10.div 10.div 5

It gets ambiguous if div takes more than one argument
y = 1.div 2.div 3 , 4

Does 4 go to 1.div or to 2.div?

I would write them like this, though as was pointed out, TIMTOWTDI
1.div(2.div 3) # one arg
1.div 2.div(3) , 4 # two args to 1.div
1.div(2.div 3 , 4) # two args to 2.div

See, in Scala, you don't need the "." when you drop the parenthesis,
so dropping them both turns out to be much nicer and clearer:

val y = 10 div (10 div 5)

Seriously? But that looks messy. It's hard to tell what is the method, what
is the variable, and how the code is formed at a glance. If 10 were stored
in a variable, it would look like div was an argument, not a method.

Yeah, I'm kidding. The point is you say those things about Ruby, because you
are used to Scala. But coming from Ruby, you'd say those things about Scala.

 

[egervari]

And the Ruby parser should actually warn you about the ambiguity. The
key to understanding when and why Rubyists (usually) use or not use
parentheses is knowing that they are dropped when they are *optional*,
and when it is, well, to taste.

Same thing with block syntax. Whether to chose do...end or {...} is a
matter of taste, and what feels "right" in the circumstances.



This isn't clear to me. Is div called on the 10, or the 5 (or on the
10 and the result of 10 div 5)? The result would be different. But I'm
pretty sure that you now consider me a particular brand of
unenlightened. But that is because I'm not familiar with Scala, nor on
what the Scala community settled on as best practices for writing
code.



That's more a matter of being used to it, than it being "bad" or
"good". object.method makes it obvious that you are calling the
#method
on the Object, and anything that follows is a parameter you pass into #method.


Absolutely. A seasoned Perl vet will consider Perl code very readable,
too, after all.


This has more to do with where you came from (IIRC, the object.method
notation is being used pretty much everywhere, from .NET, to Java, to
Ruby), and what you are used to, than actual intuitiveness.

Of course, nobody can tell you not to use parentheses when you want
to, and to use {...} when you want to, or to create a DSL for yourself
where you can use "10 div 5" as valid syntax in Ruby.

--
Phillip Gawlowski

Though the folk I have met,
(Ah, how soon!) they forget
When I've moved on to some other place,
There may be one or two,
When I've played and passed through,
Who'll remember my song or my face.

In scala, there is no difference between operators and methods. They
are all methods. So a "/" can be a method name just like "div".
Because of this, scala lets you write statements as if they were
operators:

Console println "Hey"

This is as valid in Scala as...

1 + 3

So "println" is the operator basically, or is considered the method.
It's actually both.

Another way to write the addition statement in Scala is

1.+(3)

This is the same. Because of this flexibility, it's actually much more
consistent and easily understood. You don't have to know how methods
and operators are different from each other, nor do you have to stop
and consider the precedence or the order for most cases. Scala uses a
precedence chart that is very familiar with other programming
languages and mathematics, so in Scala, it's really obvious what this
line would do:

y = 10 / 10 / 5

This would result in .2 (or 0 I guess) while...

y = 10 / (10 / 5)

.... would result in 5. I say it's intuitive because you don't have to
resort to documentation to see how it works. It works like you would
expect it to work, and I think that's good design.

I am getting used to seeing this notation a little more, but I find
myself using parenthesis anyway much of the time, especially when a
method has multiple parameters. To me, seeing this "comma" in the
middle of nowhere is a little strange. I find myself having to
mentally put the parenthesis there, and then I ask myself, why not
just type them in :/

 

[egervari]

It gets ambiguous if div takes more than one argument

y = 1.div 2.div 3 , 4

Does 4 go to 1.div or to 2.div?

I would write them like this, though as was pointed out, TIMTOWTDI
1.div(2.div 3) # one arg
1.div 2.div(3) , 4 # two args to 1.div
1.div(2.div 3 , 4) # two args to 2.div



Seriously? But that looks messy. It's hard to tell what is the method, what
is the variable, and how the code is formed at a glance. If 10 were stored
in a variable, it would look like div was an argument, not a method.

Yeah, I'm kidding. The point is you say those things about Ruby, because you
are used to Scala. But coming from Ruby, you'd say those things about Scala.

Yeah, in Scala you cannot have 2 arguments if you don't put a . and ()
in the method call. So your ambiguous examples are not valid in Scala.
They did this because they fully expect you to use the parenthesis
most of the time as a convention, and I have to say, I praise them for
this.

In Scala, you have the option, just like Ruby, but there is a clear
sense of when and when not to use it. It's not really arbitrary when
working with Scala code. I usually find myself just knowing when it's
best to drop the . and () and when to include it. I have no such
guideline really with Ruby, as a lot of code seems to make this choice
arbitrary. For the time being as I learn, I'm just using parenthesis
to avoid confusion.

Oh, your ruby example is valid syntax? I will try it. There's no way I
would even conceive of writing code like that. I hope others don't
either.

 

[Josh Cheek]

[Note: parts of this message were removed to make it a legal post.]

In Scala, you have the option, just like Ruby, but there is a clear
sense of when and when not to use it. It's not really arbitrary when
working with Scala code. I usually find myself just knowing when it's
best to drop the . and () and when to include it. I have no such
guideline really with Ruby, as a lot of code seems to make this choice
arbitrary. For the time being as I learn, I'm just using parenthesis
to avoid confusion.

Oh, your ruby example is valid syntax? I will try it. There's no way I
would even conceive of writing code like that. I hope others don't
either.

You really come across like the kind of person who goes to Japan and says
"look how much fish these people eat, look how strange the roofs of their
houses are, look how many characters are in their alphabet. This place
sucks, it isn't at all like where I come from."

 

[Phillip Gawlowski]

[snip Scala stuff]

Ruby != Scala

Ruby does things the Ruby way, Scala does things the Scala way.

If you don't like Ruby, don't use it. It's that easy.

--
Phillip Gawlowski

Though the folk I have met,
(Ah, how soon!) they forget
When I've moved on to some other place,
There may be one or two,
When I've played and passed through,
Who'll remember my song or my face.

 

[Xavier Noria]

Is there any reason tastes in style have changed? I think it would be
best to stick with the parenthesis just to make everything consistent.
It should be easier to refactor code and inline things if the
parenthesis were already there after all.

Thoughts?

I think the most used style is:

* parentheses around parameters in method definitions, and around
regular method calls with an explicit receiver. Also when the receiver
is an implicit self.

* no parentheses in procedural-like calls, eg, bare puts, class-level
macros like has_many in Active Record, assertion macros from
Test::Unit, etc.

* of course, no pointless parentheses in the conditions of an if or
while statement and friends, though these ones are normally put by
people new to the language, rather than being a matter of style

That's what I personally follow also.

 

[David Masover]

In scala, there is no difference between operators and methods. They
are all methods.

For what it's worth, this is also the case for most operators in Ruby, it's
just that pretty much all Ruby operators have special syntax. This makes
sense, I think -- for example,

a.foo = b

is equivalent to

a.foo=(b)

which seems a lot more manageable to me than

a.foo.=(b)

What would a.foo be returning, then? You could do it, it would just be clumsy,
and wouldn't work nearly as well with immutable types -- and all the basic
Ruby numeric types are immutable.

 

[ara.t.howard]

vim completion works with, or without, the '(' and ')'. same with
emacs. not sure about IDEs.

parens seems to make sense until you realize what are actually methods
in ruby


require 'rubygems' vs require('rubygems')

private 'foo' vs private('foo')

exit! vs exit!()

even?() vs even?

task :foo do ... vs taskfoo) do ...

-42.abs vs -42.abs()



learn which calls are methods, and them imagine them all with parens,
before asserting that all methods would be better without them.

the only real argument for requiring parens is so that

o.foo # returns the method foo

as in javascript. other arguments are mostly religious.

cheers.

 

[Charles Calvert]

[snip]

Same thing with block syntax. Whether to chose do...end or {...} is a
matter of taste, and what feels "right" in the circumstances.

Not entirely. There's a difference in precedence that might be
relevant in some circumstances.
<http://www.techotopia.com/index.php/Ruby_Operator_Precedence#Operator_Precedence_Table>.

 

[Tony Arcieri]

[Note: parts of this message were removed to make it a legal post.]

I just started playing around with ruby and rails, and one thing I've
noticed is that the style of the code is a little odd. People don't
use parenthesis most or even all of the time.

I find this to look messy.

For the most part dropping optional parens as much as possible is the
idiomatic style in Ruby. I'm sorry if you don't like it, but a lot of
Rubyists do. You're free to write code with more parens, if you wish.