next »

[mewse]

Perl undoubtedly has the awesomest way to implement it:

Code:

b = 10 unless (a<1 or a>5);

[bateleur]

I wish people would just look up the precedence and not sprinkle useless parentheses all over the place.

Whereas I wish people would use paretheses more instead of relying on precedence, which except in very simple cases just makes code hard to read.

[powly]

More parentheses is good; the only thing you get for not using them is errors and the necessity to constantly check if you would need some. Just put them there and you can't go wrong.

And it seems Perl does it the coolest way

[Alex May]

I wish people would just look up the precedence and not sprinkle useless parentheses all over the place.

This is the worst kind of wish. I don't know why you would wish for this sort of thing if you are a good coder.

a) Parentheses are not useless as they actually make code easier to read since your meaning is completely opaque.
b) Operator precedence can and does change between compilers and languages so your code that relies on operator precedence will do different things if you change compilers or languages.

[Average Software]

a) Parentheses are not useless as they actually make code easier to read since your meaning is completely opaque.

Strongly disagree.  Parentheses are intended to override precedence, when I see them, the first thing I do is figure out what's being overridden and why.  Extra parentheses imply an override that isn't there.  This is incredibly unclear.  The meaning of the expression is already completely opaque, it's defined by the language standard.

b) Operator precedence can and does change between compilers and languages so your code that relies on operator precedence will do different things if you change compilers or languages.

Change between languages, yes.  That's part of learning the language.  No different than any other syntax rules.  Learn the precedence, print out the chart if you have to.

If your operator precedence changes between different compilers for the same language, you have a broken language or a broken compiler.  Operator precedence is fixed by the language spec.  Coding around potential compiler bugs is an endless guessing game that you'll never win.

[Schtee]

a) Parentheses are not useless as they actually make code easier to read since your meaning is completely opaque.

Strongly disagree.  Parentheses are intended to override precedence, when I see them, the first thing I do is figure out what's being overridden and why.  Extra parentheses imply an override that isn't there.  This is incredibly unclear.  The meaning of the expression is already completely opaque, it's defined by the language standard.

That's not necesarily always the case. Sure, it can be the case, but if you want the contents of the parantheses to be seen as an atomic calculation, it can definitely add to the clarity of your code.

[Alex May]

Granted on cross-compiler precedence.

But: How can it be unclear? You evaluate the innermost parenthesis first and work outwards - that works whatever language you're using. It's FAR clearer than operator precedence which you would have to look up per-language. This is complete moonshine what you're saying to me.

[brog]

As someone with a secret lust for Lisp, I have to say: more parens plz.

[Average Software]

Granted on cross-compiler precedence.

But: How can it be unclear? You evaluate the innermost parenthesis first and work outwards - that works whatever language you're using. It's FAR clearer than operator precedence which you would have to look up per-language. This is complete moonshine what you're saying to me.

There was a large discussion about this on the GCC mailing lists.  Many experienced programmers (not trying to imply that I'm experienced, just stating that I'm not the only one that thinks this) see parentheses as a red flag.  They say "something odd is happening here, and I need to figure out what it is."  When I see parentheses that don't actually override something, I have to assume that it's a programming mistake, that the original author thought they were overriding something, possibly something crucial to the operation.  This forces me to analyze the statement and everything around it, trying to figure what the hell is going on.

Now if you drop a comment next to it, something like /* Parentheses for clarity */, then you might have something.  Otherwise, you're just confusing people.

[Hajo]

I bet only few remember all the precedence rules of their languages.

Even the simple ones like
 
a = 1 << 2 + 5;

b = 4 + 3 | 64;

can be tricky.

better use parantheses there.

Constructs like:

a = 1;
b = 1- --a;

or

a = 1;
b = ++a+a+3;

Are quite tricky, particularly for new programmers.
A moderate level of parantheses would help there I think.

[Alex May]

Relying on people remembering/looking up operator precedence when parentheses explain everything to everyone is preposterous elitism of the nerdiest, obnoxious order.

[team_q]

This reminds me of the

Code:

if (boolVariable == true)

discussion a couple months back.

[Average Software]

Relying on people remembering/looking up operator precedence when parentheses explain everything to everyone is preposterous elitism of the nerdiest, obnoxious order.

I think you're misunderstanding the point.

The issue is not what the code is doing, the issue is why the code is doing that.

The purpose of parentheses in expressions is to override precedence.  Every extra set of them forces the question, "Is something being overridden here, or are these superfluous?"  You're adding a second function to something that is syntactically identical.  Now analysis is required to determine which ones are "real" and which ones are "fake," which ones can be safely removed, and which ones can't be.

I've done maintenance programming for C++ programs that exceeded two million lines of code, that were written by at least a hundred people over the course of 10+ years.  You see so many boneheaded, "what the hell was he thinking?" mistakes that you must treat everything with suspicion.  Unnecessary parentheses can make maintenance, especially for other people, a nightmare.  It another layer of complexity that doesn't need to be added.

b = ++a+a+3;

That's undefined, no matter how you parenthesize it.  I hope you don't actually write code like that.

[wcyou]

if there were slight change to the code, say for a from 1 to 7
//original
if(a>0 && a<8 )
b=10; //adding in 6 and 7..

//bitwise
if( (a&=7)>0 )
b=10;

//works for unsigned.. otherwise..
//bitwise
if( ( (unsigned)a &= 7 ) > 0 )
b=10;

//generically for any positive number x to the power of 2
//checking from 1 to x-1
if( ( a &= (x-1)) >0 )
b = 10;

Well was interested in the topic and thought of something that might be useful.. though maybe not as readable..
This will work for C/C++ at least.. if I didn't get my logic wrong

[moi]

Meanwhile..., someone in china has released 10 games

[Dataflashsabot]

Meanwhile..., someone in china has released 10 games

I giggled softly for about 30 whole seconds.

[Nitro Crate]

Ok, I realized my old code actually did not work so I'm taking another crack at it.

This is the first result:

Code:

b += (((((a - 1) << 1) >>> 1) + 3) >>> 3) == 0 ? 10 : 0;

Unfortunately, there's still a condition but it's only one check as opposed to two.
Also there is no modulo or division. (According to someone here that slows it down.)

I'll try to get one where there is no conditions modulo or division at all.

[mewse]

I've done maintenance programming for C++ programs that exceeded two million lines of code, that were written by at least a hundred people over the course of 10+ years.  You see so many boneheaded, "what the hell was he thinking?" mistakes that you must treat everything with suspicion.  Unnecessary parentheses can make maintenance, especially for other people, a nightmare.  It another layer of complexity that doesn't need to be added.

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.   

Honestly.  When you're maintaining somebody else's code you have to analyse all the calculations anyway.  The lack of parentheses does not make a calculation automatically "right", and the presence of them does not make the analysis more difficult.  Analysing a calculation does not consist of verifying that calculations are performed according to the rules of operator precedence, rather that the calculation will produce the desired result.  The presence of parentheses simply is not a "code smell" that implies the likely presence of a bug.

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?

[SidM]

Above all else, eschew all the fancy tricks and make your code EASY TO READ and understand.

[ChevyRay]

Relying on people remembering/looking up operator precedence when parentheses explain everything to everyone is preposterous elitism of the nerdiest, obnoxious order.

This is sort of what I was thinking, though not exactly in your words.