Hacker News Reader

Comment by lpapez | Hacker News Reader

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 :)

View on HN

For 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.

I 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.

Writing 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.

Reading "if (((2*x) + 3) == z)" is annoying as well to me...

But 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_preceden...

But if it's really so onerous to read, you can always put a more ambiguous version in the comments!

To 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.

My point was that the second version is much easier to read, it’s a lot clearer.

I 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.

I 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.

It'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"...

You have nice colleagues.

Reply on news.ycombinator.com