next »

[Average Software]

If excess parentheses in calculations are anywhere in your top 100 complaints about "what were they thinking?" then I totally envy you;  you've clearly got far superior code to maintain than I do, and I'd trade places with you in a heartbeat.   

My current code is the Microsoft Office code.  Believe me, you don't want it.

and the presence of them does not make the analysis more difficult.

For me (and many other people I know) it does.  It introduces visual noise that has to be sifted through to determine the real meaning of the expression.  Some of these expressions are hideously complex, often spanning multiple lines.  We've gotten in the habit of 'pruning' them and the readability increases dramatically.

The presence of parentheses simply is not a "code smell" that implies the likely presence of a bug.

In the codebases I've worked in, it generally has been, especially when bitwise operations are involved.  If it hasn't for you, then I'd love to swap codebases.

I can totally sympathise with the frustration of being responsible for maintaining WTF-laden code, but having an extra (technically unnecessary) set of parentheses in a calculation for the purpose of clarity doesn't seem WTF-ish to me?

It's not WTF-ish if you can state with certainty that it's for clarity, with a comment or something.  That's my whole point.  There's no way to tell if a set of parentheses is there for "clarity" or for some actual semantic purpose.

I also contend that the extra parentheses don't provide clarity at all.  I find this:

Code:

if (x == 3 && y == 4 || z == 2 && a == 7)

much more readable and clear than this:

Code:

if (((x == 3) && (y == 4)) || ((z == 2) && (a == 7)))

I also don't understand the opposition to just learning the operator precedence.  It's not like you have to memorize them.  In this day and age, an operator chart is a web search away.  It's not hard.  Most of it makes perfect sense anyway, with the exception of bitwise ops, which Ritchie has admitted he gave the wrong precedence to.

[mewse]

Some of these expressions are hideously complex, often spanning multiple lines

I think that this is touching on the real problem.  In that sort of situation, I'll agree that lots of extraneous nested parentheses can certainly complicate the decoding process.  But the parentheses aren't the chief problem;  the real problem is the overly complicated and lengthy 'if' conditionals.  

Personally, I don't think that the sorts of "if" statements we were talking about in this thread were anywhere near that realm of badness (which I've experienced, too).  Of course, you're perfectly within your rights to disagree with me on that matter.


Also, can you remove the silly bulbous button in the top left of the latest Office, and give us back a proper menu bar?  Pretty please?  

[Pishtaco]

I've been using multiple lines and indentation with complex parentheses, to make the tree structure show up a bit better.

[increpare]

I've been using multiple lines and indentation with complex parentheses, to make the tree structure show up a bit better.

if you find yourself hard-coding that sort of stuff,  you might want to think about moving it to data files.

[Average Software]

Also, can you remove the silly bulbous button in the top left of the latest Office, and give us back a proper menu bar?  Pretty please?   

I work on the Mac version, no can do.

[Endurion]

This

Code:

if (x == 3 && y == 4 || z == 2 && a == 7)

makes me have to regurgitate which operators precede over which. Not good.

This

Code:

if (((x == 3) && (y == 4)) || ((z == 2) && (a == 7)))

is clearer but I prefer to rearrange longer if statements with indentation so connections come clearer:

Code:

if ( ( ( x == 3 ) 
&&     ( y == 4 ) ) 
||   ( ( z == 2 ) 
&&     ( a == 7 ) ) )

If statements spanning several lines are basically unmaintainable and I usually break them up.


Anyhow it's mostly down to opinion, so arguing about this is spaces vs tabs etc. (Spaces rule!)

[increpare]

I'd probably go with the middle ground myself

Code:

if ( ( x == 3 && y == 4  ) || ( z == 2 && a == 7 ) )

parentheses removal in general I have far less trouble with in haskell, where it's something of an amateur sport : )

[Rob Lach]

Some of these expressions are hideously complex, often spanning multiple lines.

Personally I'd be more ticked at multiple-line conditionals than excessive parentheses.

A few times I've split apart and nested if statements purely to make things more readable.

[Ben_Hurr]

But but but...

Code:

if (x == 3 && y == 4 || z == 2 && a == 7)

and

Code:

if (((x == 3) && (y == 4)) || ((z == 2) && (a == 7)))

Aren't even the same conditional!

Look at it like this:

Code:

if(x AND y OR z AND a)

VS.

Code:

if((x AND y) OR (z AND a))

z gives you a totally unpredictable result in the first conditional, I just tried it. 


But wow this is all so off topic.

[Average Software]

But but but...

Code:

if (x == 3 && y == 4 || z == 2 && a == 7)

and

Code:

if (((x == 3) && (y == 4)) || ((z == 2) && (a == 7)))

Aren't even the same conditional!

Look at it like this:

Code:

if(x AND y OR z AND a)

VS.

Code:

if((x AND y) OR (z AND a))

z gives you a totally unpredictable result in the first conditional, I just tried it. 


But wow this is all so off topic.

The are the same conditional in C.  Logical AND has precedence over logical OR.  Other languages may vary, but the only one I'm aware of off the top of my head is Ada.

[skyy]

Readability and if possible after that speed I'd say, with few comments.

But I usually use one line if-statements where ever I can, I just love them. And after using them way too much I cannot stop using them anymore... Gah!

Lousy example follows (c/c++/java and so on):

Code:

 
int tryChangingThisMagicValue(int magicalSecretValue ) {
   return magicalSecretValue > 0 ? 0 : 1;  // if statement ? true condition : false condition
}

They do have a specific name too but I cannot remember it from the top of my head, might have been mentioned in this thread already.

[Alex May]

But but but...

Code:

if (x == 3 && y == 4 || z == 2 && a == 7)

and

Code:

if (((x == 3) && (y == 4)) || ((z == 2) && (a == 7)))

Aren't even the same conditional!

Look at it like this:

Code:

if(x AND y OR z AND a)

VS.

Code:

if((x AND y) OR (z AND a))

z gives you a totally unpredictable result in the first conditional, I just tried it. 


But wow this is all so off topic.

The are the same conditional in C.  Logical AND has precedence over logical OR.  Other languages may vary, but the only one I'm aware of off the top of my head is Ada.

The confusion exists, in point of fact, whether or not it fits in with your ideals of language or users. Expecting everyone to know operator precedence is delusional and blinkered. The fact that Ben had to go off and actually try this to determine what would happen should be indicator enough that universal knowledge of operator precedence isn't fact. It's therefore practically wrong to view parentheses as having the sole purpose of overriding operator precedence regardless of their on-paper definition.

In practice people use them not to specifically override operator precedence but to ensure that their lack of knowledge of operator precedence doesn't give them a nasty surprise; it guarantees the correct execution of their calculation. And by extension, since most people are capable of thinking about others, their use of parentheses ensures that their fellow programmers (who are likely not to have committed every single operator precedence rule to memory) can understand the code without having to resort to a reference and then spend time decoding what would otherwise be a perfectly readable bit of code.

I did a survey of 135 programmers in the games industry on this subject. 127 programmers said they would prefer to maximise parenthesis use over minimising it in favour of operator precedence. 8 programmers said they would favour minimising. So what do you think is the best thing to do with your code so that it can be interpreted by as many programmers as possible?

[Schtee]

Thanks for providing some research to this, Alex. I'm totally for reduced ambiguity, and clearer code, and really, it's not lazy to say the compiler'll sort it out for you anyway.

[Alex May]

reduced ambiguity, and clearer code

This is the argument really - Av. Soft is arguing (not wrongly, but similarly not rightly) that parentheses ADD ambiguity to code as when they are not present the code is completely UNambiguous. The problem is that it's only unambiguous to the compiler and to the small subset of programmers who have full recall of all operator precedence rules, which means that for everyone else (most people) this type of code is MORE ambiguous.

I say, majority rule, add parentheses. If someone on my team took out parentheses from my code without reason I'd definitely be having words.

[Alex May]

Oh one more thing before I rest
Just to get this off my chest
The large equations you will see
Are longer than they ought to be;
Take the calculations out
So you can find without a doubt
The components you have laid
From which your larger sum is made
This can also help in cases
Where you've used in several places
Values that you have combined
To stop the compiler from recalculating them each time they occur.

[Ben_Hurr]

...The fact that Ben had to go off and actually try this to determine what would happen should be indicator enough that universal knowledge of operator precedence isn't fact. ...

Thank you.
I only later found out that the two conditionals really do behave the same, but only after much tinkering.

Still I'd rather not write a conditional like that, the only purpose it would serve is to flaunt my knowledge of precedence. 

[Rob Lach]

They do have a specific name too but I cannot remember it from the top of my head, might have been mentioned in this thread already.

"?" is called a ternary operator.

[Ben_Hurr]

Readability and if possible after that speed I'd say, with few comments.

But I usually use one line if-statements where ever I can, I just love them. And after using them way too much I cannot stop using them anymore... Gah!

Lousy example follows (c/c++/java and so on):

Code:

 
int tryChangingThisMagicValue(int magicalSecretValue ) {
   return magicalSecretValue > 0 ? 0 : 1;  // if statement ? true condition : false condition
}

They do have a specific name too but I cannot remember it from the top of my head, might have been mentioned in this thread already.

Those types of statements still make me want to rip out throats, hahaha
I can't read them at all.

[skyy]

I had the same problem at one point few years back and after figuring them out I cannot stop using them. 

[Average Software]

reduced ambiguity, and clearer code

This is the argument really - Av. Soft is arguing (not wrongly, but similarly not rightly) that parentheses ADD ambiguity to code as when they are not present the code is completely UNambiguous. The problem is that it's only unambiguous to the compiler and to the small subset of programmers who have full recall of all operator precedence rules, which means that for everyone else (most people) this type of code is MORE ambiguous.

I say, majority rule, add parentheses. If someone on my team took out parentheses from my code without reason I'd definitely be having words.

Perhaps it's domain specific.  In college I studied compiler and language theory, and in that line of work you tend do deal with more "pure" programmers that understand the details of languages and how they're parsed.  In my mind, the extra parentheses encourage ignorance of the language rules, which is to me unacceptable.  It reminds me of things like this:

Code:

SomeClass::~SomeClass()
{
    // Destructor, releases all resources.
}

Comments that explain language features.  If you don't know what a destructor is, go learn.  If you don't know that && has precedence over ||, go learn.

As said, code like:

Code:

if (a == 1 && b == 2 || c == 3 && d == 4)

Is unambiguous and easier to read for me.  This:

Code:

if (((a == 1) && (b == 2)) || ((c == 3) && (d == 4)))

Forces me to figure out where all the sets of parentheses match up to arrive exactly the same expression.  It's more work.