next »

[Parthon]

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.

How sure are you? I've used at least one language where it's the other way around. That's the reason why I use parenthesis, so it's unambiguous for less experienced programmers. Requiring all programmers to be *that* knowledgeable with compiler symantics before they are allowed to program something is just plain silly. Knowledge comes through use, and eventually those newbie programmers will be knowledgeable enough. Until then, use parenthesis, but not too much. It's okay to be a purist, a perfectionist, or an ivory tower person; but if you require others to be the same then you are a jerk.

The best if statements will make it clear what they are doing without being too complex. Don't be afraid to use a switch statements or nested ifs when they make your code easier to understand. The better the code, the easier it is to maintain and the faster you can write new code. If you've ever come back to a project that's a year old you know what I mean.

[Gold Cray]

Mathematically, AND has precedence over OR the same way * has precedence over +; however, though I've been brainwashed to know arithmetic operator precedence since I was 7 years old, I didn't actually learn about logic operator precedence until a couple of years ago. It's not second nature. Also, ab+cb has much clearer order than A^BvC^D, because 'a' and 'b' are not separated at all. They appear as a single entity. (A && B) || (C && D) uses parentheses to the same end.

[Average Software]

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.

How sure are you? I've used at least one language where it's the other way around.

I'm sure because I consider that to be part of learning the language.  I also work in Ada, where the logical operators have equal precedence, and in that language I parenthesize accordingly.

It's okay to be a purist, a perfectionist, or an ivory tower person; but if you require others to be the same then you are a jerk.

I'm simply trying to refute the ridiculous claim that adding parentheses automatically makes things clearer.  For some people, myself included, they make things harder to read and more difficult to understand.

What I really don't understand is this apparent hypocrisy:

People don't want to learn the language rules, so they embed extra crap in the name of clarity, citing that not everyone knows the rules.  Why then, do people do this:

Code:

if (x != 0 && y / x > 10)

Rather than this?

Code:

if (x != 0)
{
    if (y / x > 10)
    {

Here we have an operator rule which at least to me seems rather non-intuitive (it surprised me to learn about it), and does not hold for all languages.  This seems like basically the same situation as operator precedence, yet I don't see people advocating the second, probably more clear, "two if" form of that expression.  What's the difference?  Why is my belief that people should learn basic precedence (or at least be willing to look it up) so wrong when in this very discussion someone advocated the very similar short-circuiting technique without a backlash?

[Parthon]

It's when people say things like "If they don't know, they should learn." when it's quite possible they don't know that they don't know.

There's seems to be a gap in skills between those that are capable beginners and those that know how to use the language well. The latter tend to look down on the former and make derisive comments without actually helping. You know, things like: "If they don't know the operator precedence for && and || they should go learn."

It's possible to make simple things more confusing with added symbols, and it's possible to confuse simple things by removing symbols too. It shouldn't be needed to say "Ohai, don't use too many parenthesis, kthx." because you can see the result.

I don't have a problem with anything you said, except the line I quoted. I might have read more into it that I should have, but you came across as language elitist. Like I said: requiring people to be more skilled than they are and looking down on them for it is being a jerk. Most programmers who don't know operator precedent are too busy trying to figure out pointers.

Edit: Also, sorry if I came across as a jerk.

It's really the difference between "It's an excellent idea to learn operator precedence." versus "If you don't know operator precedence you should go and learn it."

Semantics depends on whether you come across as a kind mentor, or a belittling lecturer.

[shrimp]

I nominate Alex's poem for post of the year.

My 2p - people should of course know the operator precedence but they should write readable code, split complex "and" conditions across if statements and make temporary variables to store intermediate results where appropriate. If nothing else it helps massively when you're stepping through with the debugger.

Just thinking about what I actually do in day-to-day practice, I always put brackets around high-precedence operators, e.g. a + (b * c) even though its not strictly necessary. If I am going to put a load of &&s and ||s into one "if" I'll split it over lines, but those things don't tend to last long before they get refactored away.

[Average Software]

The latter tend to look down on the former and make derisive comments without actually helping. You know, things like: "If they don't know the operator precedence for && and || they should go learn."

I did help:

Logical AND has precedence over logical OR.

?: out prioritizes the assignment operators and the comma operator, nothing else.

I don't have a problem with anything you said, except the line I quoted. I might have read more into it that I should have, but you came across as language elitist.

Expecting people to know basic and easily referenced things is not elitist, expecting people to know virtual base class initialization orders and the details of two-phase name lookup might be.  Big difference.  If it is elitist then sign me the hell up.  I'll take that over the alternative.

[Alex May]

I don't think it's elitist in principle, just in practice. If you can't see that most programmers (ok maybe not in your line of work, but in general) don't have this knowledge, that's the problem for me. It's clearly the case, so doggedly expecting most people to buck up their ideas is a little Canutian in my opinion.

[Ben_Hurr]

Isn't this all coming down to preference now?

I could see how a long statement bursting with parenthesis would be confusing, I've seen it.
But a statement that only has parenthesis around each important block?

And breaking up 'if' statements, ohohoho, let the fun begin.

[mjau]

I think precedence of && and || is a specially big source of confusion among coders though, to the extent that gcc actually warns about it if you enable -Wall (which is generally a good idea):

Code:

warning: suggest parentheses around ‘&&’ within ‘||’

This is plenty readable, doesn't confuse less experienced coders, and doesn't produce any warnings:

Code:

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

[bateleur]

Why then, do people do this:

Code:

if (x != 0 && y / x > 10)

Rather than this?

Code:

if (x != 0)
{
    if (y / x > 10)
    {

I don't, and if anyone I was managing wrote either of those they'd get a verbal slap and be required to clean it up!

I'm simply trying to refute the ridiculous claim that adding parentheses automatically makes things clearer.  For some people, myself included, they make things harder to read and more difficult to understand.

You are, of course, quite correct.

I add logically superflous parentheses to Boolean expressions for the same reason that I don't write my code comments in Japanese, despite the fact it would clearly be easier for some people to read that way.

[ITS_Mike]

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.

I completely agree.  I always encase the various parts of if statements and math formulas in parenthesis so that they are easier to read.  From the sounds of it though, this is just another coding style which some people think is better, and some don't.

[powly]

I've started using less parentheses because of this topic. In many cases they just are innecessary and look disturbing.

In math-heavy stuff I still think some parentheses are okay (well, often they are compulsory for those cases anyways)

[Theotherguy]

Hi

a simple question i hope:

If you have alot of if statements
which is better

Code:

if a=1 or a=2 or a=3 or a=4 or a=5
 b=10
endif

or

Code:

if a=1
 b=10
elseif a=2
 b=10
elseif a=3
 b=10
elseif etc.

the endresult is the same, but i imagine the first one to be a little bit slower , because the program has to check all the  or statements , whereas the second one stops after it has found the right statement.

anybody out here knows the best practice ?

I know this has already been answered, but for this specific case, the best practice is to identify the bounds of your operation (a>=1&&a<=5) and use that instead. In fact, I am almost positive your compiler will do this for you if you use the first statement.

Secondly, the first statement is better than the second because almost all languages use what is called short circuit evaluation, and will stop whenever they reach a true condition.

Thirdly, if you had a lot of if statements (more than 5 or 6) always always use a switch statement. The compiler will optimize a switch statement into a jump table or a condition tree that will give you at best O(1) performance or at worse O(log(n)) performance. With a large set of if statements, you get at best O(n) performance.

[Gnarf]

I'm simply trying to refute the ridiculous claim that adding parentheses automatically makes things clearer.  For some people, myself included, they make things harder to read and more difficult to understand.

So are you saying that they automatically make things harder to read? That sounds just about equally stupid.

Parentheses do not automatically make code easier or harder to read. But they can be used to make code easier to read. I think/hope that's the claim people are making here. And I kind of want to believe that your point is that they can make code harder to read.

Operator precedence need not have a thing to do with it. Sometimes it just communicates better. You have two sub-expressions that you [operator-verb] together, and that's really the way it makes sense to think about it, so you enclose each sub-expression in parentheses and that works out awesomely and hooray. If it happens to amount to the same machine code without those parentheses then who gives a shit?

Though I kind of agree that using "redundant" parentheses just because you/others do not know operator precedence is a little silly. In general, depending on the code you're dealing with and so on.

[Gnarf]

This reminds me of the

Code:

if (boolVariable == true)

discussion a couple months back.

Code:

(variable = true) ifTrue: [...

Also, I've never understood why some people have spaces after left parens and before right parens. I don't really see the need for separating the parentheses from what they are enclosing. And it's typographically ugly. So there.

[LemonScented]

This might be less of a problem nowadays (although it's still considerably better to be safe than sorry), but I've had to use hokey platform-specific compilers in the past which couldn't be trusted to cope with stuff like correctly dealing with operator precedence.

Average Software is right in that it's not unreasonable to expect programmers to understand operator precedence for their language, but it's also not unreasonable to add parentheses where appropriate to clarify the intended flow of an if statement, even if they wouldn't have any effect with a sane compiler. You never know.

Basically, treat parentheses like every other language feature of any language you use: use them sparingly, but in situations in which their use is appropriate, use them without guilt.

[Zaphos]

Basically, treat parentheses like every other language feature of any language you use: use them sparingly, but in situations in which their use is appropriate, use them without guilt.

If you use every language feature sparingly, and language features include parentheses ... how does that work?  Do you just not write much code?

I would stay instead, just do whatever feels right to you, and assume the brief additional moments others may spend trying to pull apart your conditional will be made up for by the time you save by not worrying about silly details like this.  Most people making indie games are not working on a large team anyway, but if someone you're working with has strong opinions about something as minor as your if-statement-parentheses style, then they're probably a hopelessly argumentative pedant and you should just do whatever makes them happy.

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.

I think it is domain specific, yeah.  Fortunately that means whatever feels 'right' to you is more likely to feel right to your colleagues ...

[LemonScented]

Basically, treat parentheses like every other language feature of any language you use: use them sparingly, but in situations in which their use is appropriate, use them without guilt.

If you use every language feature sparingly, and language features include parentheses ... how does that work?  Do you just not write much code?

Exactly. http://www.codinghorror.com/blog/archives/000878.html

There are Holy Wars about pretty much every language feature, from simple stuff like parenthesis to more controversial stuff like templates, and what I've generally learned is that the only universally bad thing is over-engineering. If you treat EVERY feature with suspicion, as a tool which is good if wielded with restraint but which can bite you in the ass if you get too friendly with it, you end up with an attitude of trying to write code as simply and as tersely as possible. And less code, with less "clever" design patterns and advanced language features, is code which has less places for bugs to hide, and is easier to understand, debug, port and maintain.

[Average Software]

I think precedence of && and || is a specially big source of confusion among coders though, to the extent that gcc actually warns about it if you enable -Wall (which is generally a good idea):

I use -Wall, but it's followed by -Wno-parentheses, because I think that warning is obnoxious.  There was quite a row on the GCC mailing list about adding that warning to -Wall.  A lot of people (but apparently not enough) were of the opinion that the warning had no business being in -Wall.

So are you saying that they automatically make things harder to read? That sounds just about equally stupid.

No, I'm saying they don't necessarily make things clearer, and it's silly to assume that they do.  I'm using myself as a counter-example to an absolute statement.

[mewse]

the only universally bad thing is over-engineering

Kind of by definition, since that's what "over-" prefixed to anything means.

Or maybe I'm over-sensitive about that sort of grammar logic, and tend to over-analyse things overly much.  If that's the case and "over-" doesn't actually imply that it's bad, then, logically, it must be okay that I do it!  Yay, win-win situation for me!