Any downsides to writing paranthesises?

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.

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

On Mon, Sep 12, 2011 at 4:16 PM, Vladimir Van B.
[email protected] wrote:

Ruby.


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

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

  • 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

On Sep 12, 2011, at 10:16 PM, Vladimir Van B. 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.

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

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

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

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

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 Sep 12, 2011, at 8:23 PM, Dave A. 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.

Gary W.

On Mon, Sep 12, 2011 at 16:54, Florian G. [email protected]
wrote:

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

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 7:26 PM, Chad P. [email protected] 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).

…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 Sep 12, 2011, at 9:19 PM, Eric C. wrote:

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.

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

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

On Tue, Sep 13, 2011 at 7:57 AM, Vladimir Van B.
[email protected] wrote:

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’) }

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 Mon, Sep 12, 2011 at 8:09 PM, Gary W. [email protected] wrote:

On Sep 12, 2011, at 8:23 PM, Dave A. 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.

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

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 2:23 AM, serialhex [email protected] wrote:

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

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

2011/9/13 Chad P. [email protected]:

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:

– Matma R.

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

nobody would care enough to point out :wink:
Mostly, I’m just trying to help.