4 ms·
My programming teacher told me: "operator precedence is complicated, always use parenthesis if you have multiple operators in a single expression". I simply do
by lpapez 5y ago
My programming teacher told me: "operator precedence is complicated, always use parenthesis if you have multiple operators in a single expression". I simply do that, and nobody complained so far :)
- taneq 5y agoI do the same. I'm pretty confident with my BIMDAS, less so with which operators are left- vs. right-associative in what language (and I hop around languages a lot so this is a bit of a pain). My general rule is if I have to look it up, then chances are so will the next guy (who in my line of work may not even be a coder at all and will be properly flummoxed), and chucking in brackets is a double win because it saves us both time.
- OskarS 5y agoFor operators where it’s not obvious, sure, but are you really writing if (((2*x) + 3) == z) instead of if (2*x + 3 == z) If so, that’s pretty annoying.
- jraph 5y agoI would not personally go that far. I may avoid parentheses for whatever is already commonly not put between parentheses in the code base I work on and would default to parentheses otherwise. But another tool to work around this issue is to just give names to sub expressions by storing them into constants. Long expressions quickly get unreadable anyway.
- ModernMech 5y agoWriting it is annoying, yeah, but it is more comprehensible. Since code is read more than it's written, the annoyance of writing it is a fine price to pay. Also more annoying than writing it is having to debug subtle bugs caused by incorrect understanding of precedence on the part of the programmer.
- tromp 5y agoReading "if (((2*x) + 3) == z)" is annoying as well to me...
- ModernMech 5y agoBut it's clear and precise, which is the definition of good code to me, and good developer experience. Clear, consistent rules applied uniformly, everywhere. That's what I call good design. Bad developer experience is having to remember 17 levels of precedence, as in C++[1]. It leads to ridiculous things like (*foo).bar, which requires new syntax to make readable, and that's just one more thing to remember and teach. Do you know how much that confuses students new to C and C++? [1] https://en.cppreference.com/w/cpp/language/operator_precedence https://en.cppreference.com/w/cpp/language/operator_preceden... But if it's really so onerous to read, you can always put a more ambiguous version in the comments!
- eperdew 5y agoTo me, adding parentheses when using common operators signals that I should read it carefully, because normal precedence is probably broken. When that is not the case, I spend a bit more time parsing the expression for no gain as a reader.
- OskarS 5y agoMy point was that the second version is much easier to read, it’s a lot clearer.
- deleted 5y ago[deleted]
- samwillis 5y agoI do the same as well as break up the expression with intermediate variables to help explain to someone else (or myself three years down the line) what I was thinking. Any compiler/interpreter (for a language you’r using where speed is important) is going to flatten it anyway and so long expressions aren’t going to make your code faster! Always code for someone to read your code later.
- agumonkey 5y agoYou have nice colleagues.
- userbinator 5y agoIt's rather disturbing that you're being taught that way. Parentheses are used to denote that the operators are used in a way that is different from their normal precedence, so it would be a surprise if they weren't. As the saying goes, "the fish rots from the head"...