Why does a lot of code not include parenthesis?

Ruby
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

On Oct 10, 8:21 pm, egervari [email protected] wrote:

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.

3

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

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!

4

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.

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?

5

On Sunday, October 10, 2010 07:25:15 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.

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(xx + yy)

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((xx) + (yy)))

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?

6

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.

7

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

8

On Mon, Oct 11, 2010 at 6:04 AM, egervari [email protected]
wrote:

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

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.

9

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

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.

10

On 10-10-10 11:50 PM, Scott G. 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

good one!

11

On Sun, Oct 10, 2010 at 10:50 PM, Scott G. [email protected] wrote:

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

On Sun, Oct 10, 2010 at 11:04 PM, egervari [email protected]
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

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.

12

On Oct 11, 2:21 am, Phillip G. [email protected]
wrote:

doing much easier by writing it this way:
Same thing with block syntax. Whether to chose do…end or {…} is a
unenlightened. But that is because I’m not familiar with Scala, nor on

Just not the most intuitive, that’s all.
Phillip G.

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

13

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.

14

On Mon, Oct 11, 2010 at 4:04 AM, egervari [email protected]
wrote:

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

15

On Mon, Oct 11, 2010 at 10:55 AM, egervari [email protected]
wrote:
[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 G.

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.

16

On Monday, October 11, 2010 03:55:18 am egervari wrote:

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.

17

On Mon, Oct 11, 2010 at 2:25 AM, egervari [email protected]
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?

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.

18

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.

19

n Sun, Oct 10, 2010 at 6:25 PM, egervari [email protected] 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.

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.

20

On Mon, Oct 11, 2010 at 9:58 PM, ara.t.howard
[email protected]wrote:

-42.abs vs -42.abs()

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