When writing C, we've all heard people say "it doesn't hurt to use extra parenthesis" or "if in doubt, enclose it in parenthesis". Now, while both of these statements are basically correct in their applicable context, I personally feel that excessive use of parenthesis (especially where they're not needed) is indicative of an author who is uncertain of operator precedence, and frankly it drives me nuts. Personally, I place more importance on understanding and knowing operator precedence (even if it means keeping a little cheat-sheet pinned on your office wall) than on "feeling secure" by flooding/obscuring the code with just-in-case parenthesis. Am I being fussy?
Am I being fussy? no, you are being wrong. it is not just-in-case parenthesis it is avoid pesky little bugs parenthesis No bug is easier to overlook that a precedence bug and that is the case whether you know the precedences or not</i?. Erik
If a person knows a bug exists that can be resolved by using parenthesis, then use them. Arbitrarily sprinkling parenthesis throughout the code as a result of distrust of the compiler begs the question as to why you're using it in the first place.
The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility —Edsger Dijkstra
Using parens is a simple way to prevent subtle bugs. It's also useful to use space between operators. If you want less headaches down the road, write with a defensive coding style especially if the methodology has no added cost (ie more code space usage) with the actual compiled output.
I did come across a compiler once (not Keil) that generated incorrect code for too many parenteses!
There's nothing like a style discussion. Legibility means fewer skull cramps, and most experienced programmers will admit to having given themselves a few along the way. Parentheses, good use of white space, indentation, commenting end braces of nested blocks, and many other practices are intended to reduce mistakes and make the job easier. I've heard of more mistakes from sparing use parenthesis than excessive use of it. :)
parenthesis that make things clear are always good. It allows someone else to quickly see the plan without getting fingerprints on the screen tring to figure it out. But so many that they are just clutter, worse.
"parenthesis that make things clear are always good ... so many that they are just clutter, worse." The troubles is, in matters of style like this, what constitutes "too many" is a subjective matter! To some people, anything more than absolutely required by the precedence rules is "too many;" To others, the rule is "always add at least one set of parentheses for luck." And, of course, there's a spectrum of views in between!
Personally, I warmly encourage the use of a few "blind and very stupid rules", the more "stupid" the better, including the use of "unnecessary" parenthesis and white spaces between operators, because of the following reasons: - not all the programmers in a team may have the same skill, so maybe not everyone always remembers the correct precedence rules, and no cheat leaflet will help you, if you just don't read it... - the produced code may be "more readable with less effort" - you never know what you can do at 2 o'clock in the morning, when you are late in a project and deeply under pressure: if you develop rules that allow you to write your code in a very "stupid and automatic" mode, you can "fire and forget" parenthesis, operator precedence and so on, to keep your last awake brain neurons focused on what you really are doing; in my case, this will help me to defend myself (and my code) from my own stupidity.
There is, of course, the alternate argument that, if you need to be adding parentheseses, your expression is too complicated anyway! You should just break the expression into simpler steps, using intermediate variables if necessary (this shouldn't inflate the code using a modern optimising compiler...)
"parentheseses" Hmmm...
"parentheseses" Hmmm... Obviously, he meant ((parentheses)es) to indicate multiple sets thereof. Doesn't everyone know that " binds more strongly than ...?