Why does a lot of code not include parenthesis?

ruby-talk
1

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?

2

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.

···

On Oct 10, 8:21 pm, egervari <ken.egerv...@gmail.com> wrote:

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?

3

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!

···

On 10-10-10 08:25 PM, egervari wrote:

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?

--
Kind Regards,
Rajinder Yadav

4

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?

···

On Sunday, October 10, 2010 07:25:15 pm egervari wrote:

5

For starters - Perl - Wikipedia

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

···

On Oct 10, 2010, at 5:25 PM, egervari wrote:

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?

6

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.

···

On Mon, Oct 11, 2010 at 2:25 AM, egervari <ken.egervari@gmail.com> wrote:

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?

7

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.

···

n Sun, Oct 10, 2010 at 6:25 PM, egervari <ken.egervari@gmail.com> wrote:

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.

--
Tony Arcieri
Medioh! A Kudelski Brand

8

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.

[snip]

Thoughts?

My first thought was this:

"Parenthesis" is singular. "Parentheses" is plural. The second sentence
of your message should have read as follows.

    People don't use parentheses most or even all of the time.

···

On Mon, Oct 11, 2010 at 09:25:15AM +0900, egervari wrote:

--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]

9

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?

···

On Sunday, October 10, 2010 07:25:15 pm egervari wrote:

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.

10

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.

11

good one!

···

On 10-10-10 11:50 PM, Scott Gonyea wrote:

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

--
Kind Regards,
Rajinder Yadav

12

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 task(:foo) 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.

13

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)

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.

···

On Oct 10, 2010, at 9:04 PM, egervari wrote:

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.

14

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.

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:

val y = 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 #method.

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. :wink:

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. :slight_smile:

···

On Mon, Oct 11, 2010 at 6:04 AM, egervari <ken.egervari@gmail.com> wrote:

--
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.

15

- 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.

···

On Sun, Oct 10, 2010 at 10:50 PM, Scott Gonyea <scott@aitrus.org> wrote:
On Sun, Oct 10, 2010 at 11:04 PM, egervari <ken.egervari@gmail.com> wrote:

16

In this case, the negative sign is also a method. Fully parenned, it looks
like 42.-@().abs() yikes!

···

On Mon, Oct 11, 2010 at 9:58 PM, ara.t.howard <ara.t.howard@gmail.com>wrote:

-42.abs vs -42.abs()

17

I actually really like this about JavaScript, but as it turns out, JavaScript
has getters and setters. I'm guessing they've been added to the language
itself because they pretty much always existed as part of the browser's API --
think "location.href = foo" -- so it makes sense to expose them to developers.

So here, the only real question is whether it's more common to want to deal
with methods directly this way, or to want to refactor instance variables into
methods. I like that Ruby's approach has everything entirely encapsulated by
default -- attr_accessor means I always have the option to replace an instance
variable with a pair of methods. True, I have setters and getters in
JavaScript, but they're the default in Ruby.

···

On Monday, October 11, 2010 09:58:40 pm ara.t.howard wrote:

the only real argument for requiring parens is so that

  o.foo # returns the method foo

as in javascript. other arguments are mostly religious.

18

the only real argument for requiring parens is so that

o.foo # returns the method foo

as in javascript. other arguments are mostly religious.

Python is like Javascript in that regard.

  $ python
  >>> def f(n=100): return n * 2
  ...
  >>> f
  <function f at 0xb75ae6bc>
  >>> f()
  200
  >>> x = f
  >>> x(30)
  60
  >>> x = f()
  >>> x
  200

  $ irb
  irb(main):001:0> def f(n=100) n * 2 end
  => nil
  irb(main):002:0> f
  => 200
  irb(main):003:0> f()
  => 200
  irb(main):004:0> x = method(:f)
  => #<Method: Object#f>
  irb(main):005:0> x.call(30)
  => 60

I work in both Python and Ruby, and I don't have a strong preference
for either style; it just requires a different mindset.

···

On Oct 11, 7:58 pm, "ara.t.howard" <ara.t.how...@gmail.com> wrote:

19

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 :confused:

···

On Oct 11, 2:21 am, Phillip Gawlowski <cmdjackr...@googlemail.com> wrote:

On Mon, Oct 11, 2010 at 6:04 AM, egervari <ken.egerv...@gmail.com> wrote:
> 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.

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:

> val y = 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 #method.

> 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. :wink:

> 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. :slight_smile:

--
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.

20

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.

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.