Parentheses

OK, is there a general concensus on when it is OK to omit parentheses
and when it is not? I prefer skipping parentheses as often as possible,
but I’m not quite sure when I may run into trouble and when it is OK.
nikolai

···


::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)[“have”]+“fun”-97);}

Hi,

···

In message “Parentheses” on 03/10/16, Nikolai Weibull ruby-talk@pcppopper.org writes:

OK, is there a general concensus on when it is OK to omit parentheses
and when it is not? I prefer skipping parentheses as often as possible,
but I’m not quite sure when I may run into trouble and when it is OK.

foo 1,2,3 # this is OK (top level)
a = foo 3 # this is not recommended (part of expression)

						matz.

Hi!

  • Nikolai Weibull; 2003-10-15, 21:32 UTC:

OK, is there a general concensus on when it is OK to omit
parentheses and when it is not?

The answer depends on what ‘OK’ means. The obvious answer is: “You
can drop any parentheses unless doing so breakes the program.” That
doesn’t help you a lot, does it?

A better approach seems to be “Remove or add non-essential
parentheses unless the code ‘feels good’”. What ‘feels good’? This
depends on the problem you face: The following can ‘feel good’ if it
means ‘compute a sum, divide it by a value then divide it by a
quotient’:

(1.1 + 2.2) / 3.3 / ((2.2 + 3.3) / (1.0 + 0.1))

but if the same computation is done meaning ‘compute a fraction and
then divide it by another fraction’ one should rather write

((1.1 + 2.2) / 3.3) / ((2.2 + 3.3) / (1.0 + 0.1))

This is the techical side of ‘feels good’. The other side is the
programmer. Many programmers are ‘parameter-centered’ while many
others are ‘option-centered’.

One can see h.delete in two ways: As a function that takes a
parameter or as a command that understands a numerical option.
Depending on how your interpretation of h.delete is, you either
prefer using parentheses or not.

irb(main):001:0> a = [3, 1, 4, 1, 5]; b = [3, 1, 4, 1, 5]
=> [3, 1, 4, 1, 5]
irb(main):002:0> a.delete(1)
=> 1
irb(main):003:0> b.delete 1
=> 1
irb(main):004:0> a
=> [3, 4, 5]
irb(main):005:0> b
=> [3, 4, 5]

I prefer skipping parentheses as often as possible, but I’m not
quite sure when I may run into trouble and when it is OK.

Corollary of “Remove or add non-essential parentheses unless code
‘feels good’”: “Don’t remove parentheses that feel like trouble, add
parentheses where white space feels like trouble”.

Please take notice of signature! / Bitte Signature beachten!

Josef ‘Jupp’ Schugt

···


db Wenn sie mir ohne meine Einwilligung geschickt wurde, db
dpqb wird eine E-Mail > 100 kB ungelesen entsorgt dpqb
dp::qb If you send me an e-mail > 100 kB without my dp::qb
dp::::qb consent it will be silently discarded dp::::qb

When you omit parenthesis’s doesn’t that degrade readability of the code?
I’m just curious
what others have to say since I’ve seen a few folks say they like to omit
them.

-Zach

OK, is there a general concensus on when it is OK to omit parentheses
and when it is not? I prefer skipping parentheses as often as possible,
but I’m not quite sure when I may run into trouble and when it is OK.

foo 1,2,3 # this is OK (top level)
a = foo 3 # this is not recommended (part of expression)
OK, thanks. Did this change in 1.8.0 in any way?
nikolai

···


::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux[“\021%six\012\0”],(linux)[“have”]+“fun”-97);}

I’m definately in favor of omitting: I parse like natural language, not
like a machine.

Ari

···

On Wed, 2003-10-15 at 10:21, Zach Dennis wrote:

When you omit parenthesis’s doesn’t that degrade readability of the code?
I’m just curious
what others have to say since I’ve seen a few folks say they like to omit
them.

When you omit parenthesis’s doesn’t that degrade readability of the code?
I’m just curious
what others have to say since I’ve seen a few folks say they like to omit
them.

I’m definately in favor of omitting: I parse like natural language, not
like a machine.
yeah, i feel the same way often.
nikolai

···


::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux[“\021%six\012\0”],(linux)[“have”]+“fun”-97);}

I prefer the parentheses.

Parens are an ‘ambiguity reducing notation’ - without the parens, you have
to ask (from time to time) - “What is the precedence of these operators in
this language”.

Less ambiguity means clearer (human) code.

BobG

Nikolai Weibull wrote:

···

When you omit parenthesis’s doesn’t that degrade readability of the code?
I’m just curious
what others have to say since I’ve seen a few folks say they like to omit
them.

I’m definately in favor of omitting: I parse like natural language, not
like a machine.
yeah, i feel the same way often.
nikolai

Bob Gustafson said:

I prefer the parentheses.

Parens are an ‘ambiguity reducing notation’ - without the parens, you have
to ask (from time to time) - “What is the precedence of these operators in
this language”.

Less ambiguity means clearer (human) code.

I think that it depends.

#1

···

dbh.select_all sql do |row|
media_list.push QMedia.new *row
end

#2

dbh.select_all(sql) do |row|
media_list.push(QMedia.new(*row))
end

I think that #1 is easier to read than #2. However, consider:

#3

dbh.select_all sql,@client.idx do |row|
media_list.push QMedia.new me.idx,row[0],row[1]
end

#4

dbh.select_all(sql,@client.idx) do |row|
media_list.push QMedia.new(me.idx,row[0],row[1])
end

If there are multiple arguments, I prefer to use parens to group them and
help make it clearer to my eyes where the groupings are.

Kirk Haines