So (d + e*g) is an example where if you do mathematical operations you put spaces between ones that will be lower rank and higher rank no spaces. This way you could a bit faster grasp which operation will be first so (2 + 3*4) you know first to evaluate 3*4 will be 12 and then you add 2 giving 14 - but given variable names of course you are quicker to evaluate result.

But no one has time to craft such details in the code.

I only have 20 years of development experience, so I'll defer to Walter here, but if I were to write that equation it would look like `d + (e * g)`. I don't trust mine or anyone's understanding of operator precedence. Just look at how ridiculously hard to read their implementations in parsers are.

Specifically d+e*g I might make an exception for in a code review (and allow it), since it's such a widely known precedence in mathematics you can expect the reader and writer to know the way it goes, but any more complex and I'd reject it in the review for lack of parentheses.

.. that seems like a strange optimization when there's a tool to indicate to both reader and compiler which operations will be performed first: brackets!

Operator precedence is so deeply burned into my brain I would never think of adding parens for it or modify the spacing.

I will use parens, however, for << and a couple other cases. It would be a shame to use lack of spacing to imply precedence, and yet get it wrong. Oops!

I also like to line up things to make vertical formatting of similar expressions, something a formatting program doesn't do. Hence I don't use formatters.

Parens were not the main part - main part is having multiplication without spaces and addition with spaces.

I would say it is a neat detail but if no one cares or uses it - it is pretty much "feel good about yourself" use and not practical one.