5 ms·

For operators where it’s not obvious, sure, but are you really writing if (((2x) + 3) == z) instead of if (2x + 3 == z) If so, that’s pretty anno

by OskarS 5y ago

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.

jraph 5y ago
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.
ModernMech 5y ago
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.
- tromp 5y ago
  Reading "if (((2*x) + 3) == z)" is annoying as well to me...
  - ModernMech 5y ago
    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_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 ago
      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.
- OskarS 5y ago
  My point was that the second version is much easier to read, it’s a lot clearer.
deleted 5y ago
[deleted]

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 anno

by OskarS 5y ago

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.

jraph 5y ago

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.

ModernMech 5y ago

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.

tromp 5y ago
Reading "if (((2*x) + 3) == z)" is annoying as well to me...
- ModernMech 5y ago
  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_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 ago
    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.
OskarS 5y ago
My point was that the second version is much easier to read, it’s a lot clearer.

deleted 5y ago

[deleted]