The single return rule makes sense in some circumstances. I like early outs, but then tend to the single return rule. If you're breaking apart your logic to that degree that you need a return in the middle of a long function, then you may want to consider breaking apart the function. Still, I think it's best to consider it a *guideline* rather than a rule. The moment you declare something a rule, someone will find a valid reason for breaking it.
As for other "optional" code, I tend to put parentheses around any C/C++ code that depends on operator precedent. The only one *everyone* knows is * or / before + and -, otherwise, it gets parentheses, just to be clear.
I see a lot of programmers try to cram as much as possible into one line, which I'm not a fan of. As one example, I'm not a fan of assigning a variable inside an if statement. It's harder to read than several short, clear lines, and it likely compiles to the same assembly in the end. So, I'll occasionally leave a formula as several steps and explicitly declare some of the intermediate variables, even if I could have stuffed it all into one line. It's easier to debug, since you can examine the intermediate values, and it helps others to understand what's going on, since the intermediate variables have an actual name as a hint. I'm sure it bugs some people who think it's too verbose or my variable names are too long and descriptive. I don't go crazy, but neither do I stick to single letters when a word or two works better.