4 ms·

Or just put parentheses around your operands defensively even if by precedence rules not necessary as some style guides demand... went from hating and finding i

Or just put parentheses around your operands defensively even if by precedence rules not necessary as some style guides demand... went from hating and finding it too verbose to accepting and seeing advantage in that. if ((_someLongNamedVar != FooLongNameEnum::Unknown) && (_someLongNamedMap.count (_someLongNamedVar) == 0)) really not too bad? And easily enforcable and automated checkable by your favourite tool.. Named vars for subexpressions often helpful too.. but especially here you loose short-circuiting? (Not very C++ specific topic btw..?)

secondcoming 4y ago
I'm a massive fan of using parentheses even when not strictly necessary. I find it helps me visually parse the code better then a long chain of boolean expressions. I don't bother with it when a term in the expression is simple, e.g if (b1 && (b2 != b3)) rather than if ((b1) && (b1 != b3))
- mike_hock 4y ago
  I think the discussion is silly. 99.9% when the condition is "too hard to read" it's because the condition is too hard to read, period, and the correct fix is to restructure the code to have readable branch conditions, not to throw parentheses on there to make a monster expression slightly less confusing. It's like discussing the chemistry of air fresheners instead of taking the trash out more often.
  - wruza 4y ago
    Do you think that any other fix that makes it readable is incorrect?
  - usrusr 4y ago
    I'm in the opposite camp: more names means more identifiers to keep track of while reading in case they might be referenced more than once, even if it's just a short but nonetheless distracting check "ok, that's where the scope ends". There are certainly times when I take the name approach nonetheless, but more like a last resort, or when I expect full contact stepthrough with a debugger. If I deem it likely that I will get by with merely brackets and copious amounts of whitespace, that's what I'll do.
  - throwbadubadu 4y ago
    Lol no, since when is a simple expression of four operands "(a someoo b) && (c someop d)" a too hard to read condition, I could only accept at least 5 .. at least ;)
usefulcat 4y ago
It’s not clear to me how “add more parens” is necessarily an effective solution to avoiding a misplaced paren, as was the case here.
- throwbadubadu 4y ago
  See above, sure you should also structure/format appropriately, but it then similarly sticks out by the same argument that makes it easier by shortening another exoression to a name.
teo_zero 4y ago
The mistake in the article was a ")" slipped before "== 0". Exactly the same mistake can happen in your code. Your extra parentheses won't make it less likely.
- throwbadubadu 4y ago
  Disagreed, I spotted that in a split second immediately by following that now ingrained rule.

secondcoming 4y ago

I'm a massive fan of using parentheses even when not strictly necessary. I find it helps me visually parse the code better then a long chain of boolean expressions. I don't bother with it when a term in the expression is simple, e.g if (b1 && (b2 != b3)) rather than if ((b1) && (b1 != b3))

mike_hock 4y ago
I think the discussion is silly. 99.9% when the condition is "too hard to read" it's because the condition is too hard to read, period, and the correct fix is to restructure the code to have readable branch conditions, not to throw parentheses on there to make a monster expression slightly less confusing. It's like discussing the chemistry of air fresheners instead of taking the trash out more often.
- wruza 4y ago
  Do you think that any other fix that makes it readable is incorrect?
- usrusr 4y ago
  I'm in the opposite camp: more names means more identifiers to keep track of while reading in case they might be referenced more than once, even if it's just a short but nonetheless distracting check "ok, that's where the scope ends". There are certainly times when I take the name approach nonetheless, but more like a last resort, or when I expect full contact stepthrough with a debugger. If I deem it likely that I will get by with merely brackets and copious amounts of whitespace, that's what I'll do.
- throwbadubadu 4y ago
  Lol no, since when is a simple expression of four operands "(a someoo b) && (c someop d)" a too hard to read condition, I could only accept at least 5 .. at least ;)

usefulcat 4y ago

It’s not clear to me how “add more parens” is necessarily an effective solution to avoiding a misplaced paren, as was the case here.

throwbadubadu 4y ago
See above, sure you should also structure/format appropriately, but it then similarly sticks out by the same argument that makes it easier by shortening another exoression to a name.

teo_zero 4y ago

The mistake in the article was a ")" slipped before "== 0". Exactly the same mistake can happen in your code. Your extra parentheses won't make it less likely.

throwbadubadu 4y ago
Disagreed, I spotted that in a split second immediately by following that now ingrained rule.