Any downsides to writing paranthesises?

ruby-talk
1

Im a newbie programmer who is trying to learn Ruby after having just
learned the basics of Python. Being used to Python I very much like
having paranthesises when I code because for me it is easier to read and
I also think it looks more structured.

I know that Ruby encourages you to not use paranthesises in most cases,
but my question is: are there any downsides to using paranthesises? I
dont know much about programming and I would very much like to know if
there is a problem with me using paranthesises pretty much everywhere in
Ruby.

···

--
Posted via http://www.ruby-forum.com/.

2

while there isn't anything implicitly *wrong* with using parens all
over the place, IMO (and in most ruby-ists opinion probably) an
overabundance of parens looks ugly. case in point:

"foo".to_a().length()
# vs
"foo".to_a.length

the first, with the un-needed parens is kind of ugly, the second, not
so much. (in fact, the fact that i *must* include the parens with
functions that take no arguments infuriates me to no end! it's like
ending every line with a freaking semicolon!!! OOHHHH!!!! STAB
PEOPLE!!!!!!)

but in the end, it's your code, do what you will
hex

···

On Mon, Sep 12, 2011 at 4:16 PM, Vladimir Van Bauenhoffer <cluny_gisslaren@hotmail.com> wrote:

Im a newbie programmer who is trying to learn Ruby after having just
learned the basics of Python. Being used to Python I very much like
having paranthesises when I code because for me it is easier to read and
I also think it looks more structured.

I know that Ruby encourages you to not use paranthesises in most cases,
but my question is: are there any downsides to using paranthesises? I
dont know much about programming and I would very much like to know if
there is a problem with me using paranthesises pretty much everywhere in
Ruby.

--
Posted via http://www.ruby-forum.com/\.

--
* my blog is cooler than yours: http://serialhex.github.com
* The wise man said: "Never argue with an idiot. They bring you down
to their level and beat you with experience."
* As a programmer, it is your job to put yourself out of business.
What you do today can be automated tomorrow. ~Doug McIlroy

3

Just a convention. As long as you're just writing for yourself, do
whatever you like; if you ever join some open-source projects, though,
you may have to adjust to majority's coding style.

Personally I find parentheseless code just as easy to read as
parenthesized one (even easier, in some cases, when you'd have to nest
parens three-deep...) and much easier to write.

-- Matma Rex

4

I wouldn't say Ruby encourages you to. It leaves it up to you, as long as
your code is unambiguous to the interpreter. For example, one of the most
prominent style guides by cneukirchen[1] encourages the use of parantheses
in quite a few contexts (e.g. when calling methods to reuse their
return value, in argument and some parameter lists). So code with
parenthesis is perfectly fine and widely used. You might have sparked another
discussion about this now, though :).

Regards,
Florian

[1]: styleguide/RUBY-STYLE at master · leahneukirchen/styleguide · GitHub

···

On Sep 12, 2011, at 10:16 PM, Vladimir Van Bauenhoffer wrote:

Im a newbie programmer who is trying to learn Ruby after having just
learned the basics of Python. Being used to Python I very much like
having paranthesises when I code because for me it is easier to read and
I also think it looks more structured.

I know that Ruby encourages you to not use paranthesises in most cases,
but my question is: are there any downsides to using paranthesises? I
dont know much about programming and I would very much like to know if
there is a problem with me using paranthesises pretty much everywhere in
Ruby.

5

.serialhex .. wrote in post #1021524:

while there isn't anything implicitly *wrong* with usingparens all
over the place, IMO (and in most ruby-ists opinion probably) an
overabundance of parens looks ugly. case in point:

"foo".to_a().length()
# vs
"foo".to_a.length

the first, with the un-needed parens is kind of ugly, the second, not
so much. (in fact, the fact that i *must* include the parens with
functions that take no arguments infuriates me to no end! it's like
ending every line with a freaking semicolon!!! OOHHHH!!!! STAB
PEOPLE!!!!!!)

but in the end, it's your code, do what you will
hex

I agree that having to write empty paranthesises is not all that great
and that is not something I would do in Ruby. I mean that I like to
write them in places like:

Dir.glob("*txt")
array.delete_at(1)

in other words, after methods and the like.

···

--
Posted via http://www.ruby-forum.com/\.

6

Err . . . just a note:

"Parenthesis" is singular, and plural is "parentheses". "Parenthesises"
is not correct pluralization, though it is a third-person present form of
parenthesise, the British spelling of parethesize. Thus, what you said
probably should have been "parenthesisless" (not parentheseless), and
what the originator of this thread said should have been "parentheses"
(not parenthesises).

···

On Tue, Sep 13, 2011 at 05:41:41AM +0900, Bartosz Dziewoński wrote:

Personally I find parentheseless code just as easy to read as
parenthesized one (even easier, in some cases, when you'd have to nest
parens three-deep...) and much easier to write.

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

7

Yup. :slight_smile: Another reason to omit the parens is so that clients don't
need to be tweaked by adding or removing parens if implementation
moves between a function, a public variable (yes, generally bad
practice, but it happens), or a var with an attr_reader (ah, that's
better!).

-Dave

···

On Mon, Sep 12, 2011 at 16:54, Florian Gilcher <flo@andersground.net> wrote:

So code with
parenthesis is perfectly fine and widely used. You might have sparked another
discussion about this now, though :).

--
Main Web Site: davearonson.com | LOOKING FOR WORK,
Programming Blog: codosaur.us | preferably RoR, in NoVa/DC;
Excellence Blog: dare2xl.com | see main web site.

8

.serialhex .. wrote in post #1021524:
>
> ```
> "foo".to_a().length()
> # vs
> "foo".to_a.length
> ```

I agree that having to write empty paranthesises is not all that great
and that is not something I would do in Ruby. I mean that I like to
write them in places like:

Dir.glob("*txt")
array.delete_at(1)

To my knowledge, there is no technical difference for executing code
between when it has parentheses and when it lacks them, as long as you
don't run into precedence problems. For instance, these two lines of
code have the same effects when executed:

    Dir.glob("*txt")
    Dir.glob "*txt"

These two, however, do not:

    Dir.glob("txt").map {|x| x.sub(/foo/, 'bar') }
    Dir.glob "txt".map {|x| x.sub(/foo/, 'bar') }

Similarly, these are equivalent:

    hash.delete(1)
    hash.delete 1

These two, on the other hand, are not:

    hash.delete 1.to_sym
    hash.delete(1).to_sym

These have the same effect, of course:

    hash.delete 1.to_sym
    hash.delete(1.to_sym)

I find the first of the two more immediately readable than the second. I
suppose your mileage may vary.

in other words, after methods and the like.

You seem unaware that to_a and length, in the above example provided by
hex, *are* methods.

···

On Tue, Sep 13, 2011 at 05:50:35AM +0900, Vladimir Van Bauenhoffer wrote:

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

9

I agree with this except that there is no such thing as a 'public variable' in Ruby. Not sure what you are referring to there.

Gary Wright

···

On Sep 12, 2011, at 8:23 PM, Dave Aronson wrote:

Yup. :slight_smile: Another reason to omit the parens is so that clients don't
need to be tweaked by adding or removing parens if implementation
moves between a function, a public variable (yes, generally bad
practice, but it happens), or a var with an attr_reader (ah, that's
better!).

10

...witch is why i make my life simplr, just say parens! most of time
the ppl i am talkin to know whut i am tlakin aboot. and it savs me A)
keystrikes and 2) halving to be gramtikally corekt.

hex

p.s. was that annoying enough? or should i try harder next time :stuck_out_tongue:
seriously though, quite informative.

···

On Mon, Sep 12, 2011 at 7:26 PM, Chad Perrin <code@apotheon.net> wrote:

"Parenthesis" is singular, and plural is "parentheses". "Parenthesises"
is not correct pluralization, though it is a third-person present form of
parenthesise, the British spelling of parethesize. Thus, what you said
probably should have been "parenthesisless" (not parentheseless), and
what the originator of this thread said should have been "parentheses"
(not parenthesises).

--
* my blog is cooler than yours: http://serialhex.github.com
* The wise man said: "Never argue with an idiot. They bring you down
to their level and beat you with experience."
* As a programmer, it is your job to put yourself out of business.
What you do today can be automated tomorrow. ~Doug McIlroy

11

Yes, I know. I mistyped and only realized it later, but I thought
nobody would care enough to point out :wink:

-- Matma Rex

···

2011/9/13 Chad Perrin <code@apotheon.net>:

On Tue, Sep 13, 2011 at 05:41:41AM +0900, Bartosz Dziewoński wrote:

Personally I find parentheseless code just as easy to read as
parenthesized one (even easier, in some cases, when you'd have to nest
parens three-deep...) and much easier to write.

Err . . . just a note:

"Parenthesis" is singular, and plural is "parentheses". "Parenthesises"
is not correct pluralization, though it is a third-person present form of
parenthesise, the British spelling of parethesize. Thus, what you said
probably should have been "parenthesisless" (not parentheseless), and
what the originator of this thread said should have been "parentheses"
(not parenthesises).

12

And a var with an attr_reader is really just a method. I've seen this
justification of going without parentheses in a book, too, and it
didn't make any more sense to me then.

The only thing I can think of with respect to ease of tweaking is that
you could change between a *local* variable and a method without
changing the actual usages; but I don't see how that's very likely to
be an issue in practice.

···

On Mon, Sep 12, 2011 at 8:09 PM, Gary Wright <gwtmp01@mac.com> wrote:

On Sep 12, 2011, at 8:23 PM, Dave Aronson wrote:

Yup. :slight_smile: Another reason to omit the parens is so that clients don't
need to be tweaked by adding or removing parens if implementation
moves between a function, a public variable (yes, generally bad
practice, but it happens), or a var with an attr_reader (ah, that's
better!).

I agree with this except that there is no such thing as a 'public variable' in Ruby. Not sure what you are referring to there.

13

Chad Perrin wrote in post #1021546:

To my knowledge, there is no technical difference for executing code
between when it has parentheses and when it lacks them, as long as you
don't run into precedence problems.

What does precedence problems mean exactly?

For instance, these two lines of
code have the same effects when executed:

    Dir.glob("*txt")
    Dir.glob "*txt"

These two, however, do not:

    Dir.glob("txt").map {|x| x.sub(/foo/, 'bar') }
    Dir.glob "txt".map {|x| x.sub(/foo/, 'bar') }

Does that mean you have to use paranthesises if you want to use the code
above?

You seem unaware that to_a and length, in the above example provided by
hex, *are* methods.

Yeah Im facepalming right now, of course they are methods. Silly me.

···

--
Posted via http://www.ruby-forum.com/\.

14

A better effort might have looked like this:

...wich is why i make my life simpaler, just say parens! most of time
the ppl i am talkin too know what i am talkin about. and it saves me A)
keystrikes and 2) halving to be gramatickly coreckt.

I think that might make it a little bit less certain you were kidding.

I should probably stop now. This has gone off the topic more than
enough. Thanks for the compliment, though.

···

On Tue, Sep 13, 2011 at 10:23:19AM +0900, serialhex wrote:

...witch is why i make my life simplr, just say parens! most of time
the ppl i am talkin to know whut i am tlakin aboot. and it savs me A)
keystrikes and 2) halving to be gramtikally corekt.

hex

p.s. was that annoying enough? or should i try harder next time :stuck_out_tongue:
seriously though, quite informative.

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

15

What saves you time adds reading and comprehension time for everyone else. :slight_smile:

···

On Tue, Sep 13, 2011 at 2:23 AM, serialhex <serialhex@gmail.com> wrote:

and it savs me A)
keystrikes and 2) halving to be gramtikally corekt.

16

Mostly, I'm just trying to help.

···

On Tue, Sep 13, 2011 at 10:56:18PM +0900, Bartosz Dziewoński wrote:

2011/9/13 Chad Perrin <code@apotheon.net>:
>
> "Parenthesis" is singular, and plural is "parentheses".
> "Parenthesises" is not correct pluralization, though it is a
> third-person present form of parenthesise, the British spelling of
> parethesize. Thus, what you said probably should have been
> "parenthesisless" (not parentheseless), and what the originator of
> this thread said should have been "parentheses" (not parenthesises).

Yes, I know. I mistyped and only realized it later, but I thought
nobody would care enough to point out :wink:

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

17

I think the "uniform access principle" is a good one (http://en.wikipedia.org/wiki/Uniform_access_principle\). I was just flagging the "public variable" terminology, which I don't think is meaningful in a Ruby context. Instance variables are never directly accessible in Ruby so there is no concept of access control to instance variables. They must be accessed through instance methods (Kernel#instance_variable_get is the "loophole" to this but even that is a method and not simply syntax).

Gary Wright

···

On Sep 12, 2011, at 9:19 PM, Eric Christopherson wrote:

On Mon, Sep 12, 2011 at 8:09 PM, Gary Wright <gwtmp01@mac.com> wrote:

On Sep 12, 2011, at 8:23 PM, Dave Aronson wrote:

Yup. :slight_smile: Another reason to omit the parens is so that clients don't
need to be tweaked by adding or removing parens if implementation
moves between a function, a public variable (yes, generally bad
practice, but it happens), or a var with an attr_reader (ah, that's
better!).

I agree with this except that there is no such thing as a 'public variable' in Ruby. Not sure what you are referring to there.

And a var with an attr_reader is really just a method. I've seen this
justification of going without parentheses in a book, too, and it
didn't make any more sense to me then.

18

Precedence problems mean that the parser understands the second line
as you calling the map method on the "txt" string, not on the result
of Dir.glob, so the second line is equivalent to:

Dir.glob("txt".map {|x| x.sub(/foo/, 'bar') })

which is clearly not the same as the first line.

Jesus.

···

On Tue, Sep 13, 2011 at 7:57 AM, Vladimir Van Bauenhoffer <cluny_gisslaren@hotmail.com> wrote:

Chad Perrin wrote in post #1021546:

To my knowledge, there is no technical difference for executing code
between when it has parentheses and when it lacks them, as long as you
don't run into precedence problems.

What does precedence problems mean exactly?

For instance, these two lines of
code have the same effects when executed:

Dir\.glob\(&quot;\*txt&quot;\)
Dir\.glob &quot;\*txt&quot;

These two, however, do not:

Dir\.glob\(&quot;txt&quot;\)\.map \{|x| x\.sub\(/foo/, &#39;bar&#39;\) \}
Dir\.glob &quot;txt&quot;\.map \{|x| x\.sub\(/foo/, &#39;bar&#39;\) \}