Ask Slashdot: When Do You Include 'Unnecessary' Code? (sas.com)

"For more than 20 years I've been putting semicolons at the end of programming statements in SAS, C/C++, and Java/Javascript," writes Rick Wicklin, a researcher in computational statistics at SAS. "But lately I've been working in a computer language that does not require semicolons. Nevertheless... I catch myself typing unnecessary semicolons out of habit," he writes, while at other times "I include optional statements in my programs for clarity, readability, or to practice defensive programming." While Wicklin's post is geared towards SAS programming, Slashdot reader theodp writes that the question is a language-agnostic one: ...when to include technically-unnecessary code -- e.g., variable declarations, superfluous punctuation, block constructs for single statements, values for optional parameters that are the defaults, debugging/validation statements, non-critical error handling, explicitly destroying objects that would otherwise be deleted on exit, labeled NEXT statements, full qualification of objects/methods, unneeded code from templates...
He's wondering if other Slashdot readers have trouble tolerating their co-workers' unnecessary codes choices (which he demonstrates with a video clip from Silicon Valley). So leave your answers in the comments. When do you do include 'unnecessary' code in your programs -- and why?

Comments

I avoid reliance on operator precedence

[iceco2]

I add "unnecessary" parentheses to complex expressions in order to avoid the mental burden of thinking of operator precedence. I instruct my team to do the same.
Obviously if I can name a sub expression reasonably I just extract it, this is often enough not a reasonable solution.
Usually I prefer terse code, but the above is a fairly common exception.

Re:Almost never

[TechyImmigrant]

I usually write all my C++ if statements, even if they contain just one statement, with curly brackets. I read somewhere it was better to do this, but I can't remember why.
 

It's a land mine. When you later add a second line to the conditionally executed section, you then need to notice the lack of braces and add them or you will not get the intended behaviour.

Re:Anything for work

[Dutch Gun]

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.