Then you're forcing the maintainers to memorize an operator precedence table to infer your meaning, instead of writing it explictly. At the time you write you code, you know exactly what you mean, and where the parens must go, but you then take away this information in order to promote "consiseness". This is, in my experience, where mistakes tend to happen. I don't think the risk is worth the gain.
For one thing, I don't think it's worth it to do that much work in stripping down my code. Whenever I find that I've really got too many layers of parens, then I've always found that my code itself is too complex; so I simplify it, or break it into sub-expressions.
For me, it's all about minimizing the time spent proving the code is correct; if I have to spend time pulling up an obscure table in my memory and cross checking it, there's a chance I'll fuck it up, especially if I'm sick, over-tired, or hungry. Worse yet, I have to carefully cross check code any code that doesn't include parens (and look up that damned table(!)), because I don't know if you were sick, tired, or hungry when you wrote the code, so I don't know if you intended the odd precedence the code may happen to be running with, or if it's a horrible mistake. An explict encoding (and decent comments!) correct both problems.
Do whatever works best for you, but in my experience, minimizing the number of things I have to think about to get the code right leads to fewer mistakes, and fewer bugfixes six months after I've forgotten about the project and what it's all about.
--
Ytrew
In reply to Re^2: What's so bad about &function(...)?
by Anonymous Monk
in thread What's so bad about &function(...)?
by japhy
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |