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

"Unnecessary" code?

[Anonymous Coward]

All of my code is unnecessary, you insensitive clod!

Anything for work

[Anonymous Coward]

I'll add extra intermediate variables, break up lines to make them as short as possible, and use extra verbose variable names along with explanatory comments of the logic of each object/function. The goal is to make it so that anyone reading the class for the first time with no prior experience can understand its purpose and basic function without having to spend 5 minutes deobfuscating the code. Yes you generally can golf most any class into a single line, but it's unmaintainable even to its original creator after a couple weeks.

That said, for personal consumption code, I don't generally bother going to that much effort to make my code clean/clear.

Re:Anything for work

[lgw]

None of the "unnecessary code" in TFS would be translated into executable instructions. Heck, the better the compiler's optimizer, the harder it is to add anything that's semantically equivalent but causes wasted object code.

Re:Anything for work

[swilver]

Ugh, single return rule sucks the worst. Nothing like having to read through dozens of lines of code just to see if the result wouldn't change somewhere halfway when an early return could have made it clear in an instant.

Re:Anything for work

[chipschap]

My approach also. Main goal for me is to make code readable enough that only minimal commenting is necessary. If personal stuff gets big enough that picking it up in a year would take effort then it gets the ultra explicit, readable and immediately understandable treatment.

I agree with both this and the poster above, except that even if minimal commenting is truly necessary I'll still put in plenty of comments. A couple of months later I want the code to make sense to me as well as others, and it's so easy to forget what you were thinking at the time. My shorter programs tend to have at least as many lines of comments as of code. Perhaps that's overkill but there's no harm in it. Writing comments doesn't take a lot of time and it may save tons of time down the road.

Side note: some years ago I went to a class by an "expert" who said that code should be so clear it never needs comments (sort of okay so far) so therefore code should never have comments in it (I walked out at that point).

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.

Re:Anything for work

[Anonymous Coward]

The code says WHAT you are doing
The comments should say WHY you are doing it.

I took over a project a few years back. The developer had no idea about :-
- comments
- Functions and Procedures
- Everything was in if...then... else monolithic structures.

As a result thousands of lines were replicated many many times and totally unmaintable.
My background was in assembler code. We had one comment per line as a minimum.

Re:Anything for work

[fahrbot-bot]

Side note: some years ago I went to a class by an "expert" who said that code should be so clear it never needs comments (sort of okay so far) so therefore code should never have comments in it (I walked out at that point).

Comments describing exactly what you're doing should be relatively unnecessary. However, comments as to *why* you're (not) doing something or how you're doing something, especially if it's non-obvious and/or "clever" are always appropriate. Code is changed for many reasons. Commentary can help understanding of various facets in various ways.

Personally, I think clear logic and consistent style are most helpful for both coding and commenting. Most people should be able to skim your code and have a general understanding of what's going on and why. I always try to write my code so that more junior people (and, quite frankly, even more senior people) on our team will be able to learn from my examples and work with what I've written. (You know, in case I get hit by a bus tomorrow.)

Re:Anything for work

[BlackHawk-666]

I try to write my code as if I'm explaining it to a new, but competent coder. This serves me well when I write articles and include snippets of the code, as well as when I try and remember what the hell I was doing.

I also make heavy use of: // NOTE: // TODO: // HACK:

and their ilk.

Re:Anything for work

[Anonymous Coward]

To me code should not be commented to hell, it should be commented to a level that a make the code understandable to a programmer or average skill. Most code is self explanatory, I actually read code better than English it is always accurately describes what the program is doing, and it is always up to date. Yes there is a place for comments, in code that is complex or relies mathmatical principles, or an API.

Too many times have I seen coding standards that require you to comment every function, you end with copious amounts of code like this:

/**
  * sets X
  * X IN int
  */
void SomeClass::setX(int x)

The comment above is worse that useless, it takes time for me to read it, write it, and maintain it.

More is not always better than less, as in non-fiction writing you should say just enough to explain the concept to your target audience, and no more. I this is a concept they never taught me in school but should have. They should say give me an essay with X good points, not Y words. So through school I used to make my essays much much much longer by putting in superfluous words.

Re:Anything for work

[Anonymous Coward]

if (auto x = SomeTest ())
{
}

How about

if ( ( auto x = SomeTest() ) )
{
}

Re:Anything for work

[Anonymous Coward]

I like to sprinkle //FIXME around my code. Sometimes I even put it where something needs to be fixed, though I never say what.

Re: Anything for work

[chipschap]

Remember that comments always lie. Still put them but don't trust them.

Actually this can work to your advantage when debugging. If the comment explains what is supposed to be going on, but that's not happening, it can help narrow things down.

Simple reason...

[QuietLagoon]

I put the unnecessary code in so that the next programmer who likes to complain has something to complain about besides my real code.

.
There are some programmers who like to complain about other people's code (it seems to make them think they are a better coder), so why not give them something intended for them to complain about?

Re: Simple reason...

[beelsebob]

No, that's you. The point he's making is that it's not unnecessary to miss out these initialisations in *any* compiler, even (and I'm not sure these actually exist), ones that initialise every variable to 0. You're writing C, not "C for this specific compiler", and that means that no matter the compiler implementation, the value stored in an uninitialised variable is undefined, and as soon as you read an uninitialised value, your whole program has an undefined behaviour.

Re: Simple reason...

[Immerman]

Quite. Reminds me of the definition of "undefined behavior":
It compiles perfectly.
It debugs perfectly.
It works perfectly throughout all functionality and QA testing.
It explodes in the worst possible manner when proper functioning is actually important.

Code doesn't need punctuation

[guruevi]

In effect most punctuation, indented blocks etc is superfluous to a computer. Is your code more or less readable with whatever construct you include? What if you add more code between eg your declaration and your use, would it still be obvious?

That's why languages without those construct are a pain to work with, you add a bunch of code and suddenly you've lost whether you're 4 or 5 tabs deep when the tabulation decreases. I like to add comments to the end brackets of regular code myself and add brackets to all if statements. It's superfluous but it's harder to rewrite a conditional one liner into a multiline code after the fact.

Re:Code doesn't need punctuation

[danthemanvsqz]

The problem is that you write code that's 4 or 5 tabs deep. Keep your code simple and obvious, also how hard is to test code that have 4 or 5 nested code blocks vs code that has only 1 or 2 nested code blocks?

Re:Code doesn't need punctuation

[Immerman]

Depends on what exactly you're doing. As a general rule I prefer to avoid deeply nested code, but I've also written some code where a large block of code all interacted with a large amount of data, so that there were no natural "separation planes" to decompose it into smaller blocks without creating subfunctions that would themselves take dozens of parameters that might (or might not) be modified, making the whole even more error-prone and difficult to understand.

Not a common occurrence I'll grant you, but sometimes the task at hand really is that ugly.

I've also employed deep nesting in special purpose situations code where it could be naturally decomposed into subfunctions, but those subfunctions would themselves be extremely brief with near-zero chance of reuse. At that point the overhead of function decomposition can rival the time to actually get it working, so unless there's a dramatic improvement in clarity or I've got time to spare, I'm unlikely to bother.

Re:Code doesn't need punctuation

[guruevi]

The problem is and remains readability, not testability. You can perfectly test minified JavaScript (all the superfluous is removed). Additionally, your code may test correctly but still not give the results expected, especially when you're doing things like write mathematical code or image processing (you can't test for correctness if you don't know the result yet). Manually scrolling and looping through a program in your head is not easy with everything is in superfluous functions. And that is precisely the code where you'll easily go 5 loops or more deep and left spinning, dazed and confused with a beginner language like Python.

When it reduces the cognitive burden

[El Cubano]

When Do You Include 'Unnecessary' Code?

Here is how I make the determination: if it reduces my cognitive burden now, later when I return to the same code, or other programmers who will have to maintain it, then I include it

These days, a programmers time is nearly always far and away the most expensive commodity employed in any project. Why should I spend time asking myself about minutiae rather than focusing on architecture and algorithms?

Re:When it reduces the cognitive burden

[Greyfox]

"These Days?" They invented OO because the maintenance phase of the project was always very expensive, and they were looking for ways to reduce those costs. Fortunately they solved that problem with Agile -- now you just work on the project for years until it's done, then throw all the code away and start over again. No maintenance costs, it's genius!

Code should be as concise as possible.

[Hans Lehmann]

I never use variable names of more than one character unless all possible single character names have already been used, which rarely happens. I never indent blocks; extra white space is only superfluous. I never do in six lines of code what can be done in one long convoluted line. If the person that needs to maintain my code can't make sense of it, too bad. They're probably just a sloppy programmer.

Re:Code should be as concise as possible.

[Anonymous Coward]

You use variable names? That's so last century! Modern code doesn't use named variables:

postMessage(story("https://developers.slashdot.org/story/16/07/23/0357235"), createMessage(MsgType.ACPost).addSubject("Re:"+previousMsg().subject).addGenderNuteralBody(createText("You use variable names?"+Spacing.Sentence+"That's so last century!"), Lang.English).convertTo(OS.getDefaultLang()))

Re:Code should be as concise as possible.

[goose-incarnated]

Then I clearly need to step up my game and have them call one another for no reason that anyone reading my code will ever be able to understand.

You do. You really do. Until you do, we're revoking your evil overmind badge :-) Here is a function that is never called but cannot be easily proven to be called or not:

struct usethisoften {
...
};
...
void usethisoften (void) {
printf ("Doesn't get called!);
}
...
typedef void (*ftype) (void);
...
ftype foo[] = {
funcs, that, get, called, usethisoften, otherfuncs, go, here, will not get called,
};
...
foo[somevar % sizeof (int)] (); // Here it never gets called!!! Looks harmless

Just ensure that the 'usethisoften' struct is used everywhere. The last line that can never call your "don't-call" functions will be glossed over by the maintainer who assumes that you're simply trying not to overrun the array because they've still got another 1500 occurrences of "usethisoften" to double-check.

Bonus: if this is ever discovered you can claim it was an honest error! Plausible Deniability!

View from on high

[Okian Warrior]

I used to make firmware that goes into aircraft instruments. The FAA has some guidelines on this.

Unnecessary code is generated machine code, and the rule is that you can have none of it. Source code doesn't matter, if it's ifdef'd out it's the same as commentary.

The theory is that if execution takes an unexpected jump, it can't land in anything that isn't specific to the purpose of the device. Some people take this to extremes, writing new versions of printf() that omit the floating point and pointer output formats when they're not used in the system.

However, if a buffer overflow causes the program to jump, it can't land in the middle of the pointer formatting section and send a pointer to the airspeed computer instead of the decimal altitude.

What the OP is talking about is unnecessary source, which is a different matter.

IBM did studies of bug frequency, and concluded that the number of bugs in a program depends on the number of source lines a programmer can see at any one moment. Big screens allow the programmer to view more lines of code at once, little screens require reading the code through a soda-straw.

Their studies showed that simple code-tightening techniques reduced the number of bugs. Placing the brace on the if-statement, for example, allows one more line to be viewed in the window. Omitting braces altogether for single-statement "if" saves another line. Using 120-char width lines instead of 80 allows fewer wrapped lines, and so on.

There is a competing goal of readability, so tightening can't be taken too far. The complex perl-style or APL-style "everything on a single line" construct goes the opposite direction - too much info and it becomes hard to understand at a glance.

Typical C-like syntax with line-tightening techniques is easy to read, and presents probably an optimal view of code to the engineer.

Braces on their own act like vertical whitespace. Requiring one-and-only-one exit from a subroutine leads to convoluted and chevron code (where the code looks like a big sideways "V" and the hints of indenting is lost). Requiring all definitions at the top of the module requires the reader to flip back-and-forth, and requiring Hungarian notation makes the code look like gobbledy-gook.

Dump it all.

Name your variables clearly, using nouns for objects and verbs for actions. Name your subroutines after their functions. Tighten your code to make it terse, but keep it readable.

Re:View from on high

[TechyImmigrant]

It's great now that we have huge screens, we don't have any more bugs.

Code should read like a good story

[Anonymous Coward]

A function should read like a good short story. Set the scene, develop the characters, advance to the climax, then there's the denumont/ epilog (sp?) where loose ends get resolved. Add comments if the story is hard to follow, don't if it's not. If the story is too long, create some helper functions.

A dash of humor here and there helps keep things entertaining, but go easy on it.

Remember, some software archaeologist may have to go back in 5 or 10 years and figure out what the heck the code does to fix a problem -- and that guy may very well be you.

I'm completely serious. This is what I do, and I actually enjoy going back through my 10 year old code (I've got a nice stable job)

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.

I'm in my sixties

[Intron]

Since I make a ton of money, and my boss is itching to fire me and replace me with a Syrian refugee who will work for cafeteria scraps, I make heavy use of 6-level deep macros and the C downto operator: while (i --> 0)

Xtra code when there is no cost

[mysticgoat]

Caveat: I am retired. Programming was a major part of my career between 1995 and 2005 but I mostly do HTML/CSS these days, with only enough PHP to glue others' existing scripts together.

What I determined back in the day is that efficient coding is unnecessary for performance when the wetware BKAC would always be the primary limiter on speed. Since virtually all of my work was repurposing documents from old versions of Word, Excel, WordPerfect, Lotus1-2-3, and other outdated apps to newer standards (mostly early HTML), I did not have to worry about shaving off microseconds. The typing speed of the person selecting the raw data had more impact on performance than the programming. So I was much more concerned with whether I would be able to rewrite a handler for a Windows3.11 app to work on a Windows98 version, if that need arose.

So I worked mostly in Perl using the Tk graphic interface and Javascript front ends, which made rapid development and easy revisions to meet new criteria possible. I used explicit declarations, human-readable naming conventions, extra punctuation, and the long way around the barn whenever the shorter routes looked like they might cause head-scratching later on.

If I had been working in an environment where microseconds counted, I would have used a compiled language and a different approach.

My old-timer's advice to you young'uns: Look at the environment you are coding in and match your coding style to fit its shape. Eschew becoming the cleverest code monkey in the cube farm and focus instead on becoming wiser than all the others.

Whenever I want really...

[RyanFenton]

I code for thousands of mostly-unique commercial software products a year, using 8 languages (mostly C#), for many dozens of major customers, and lots of smaller ones.

Because of this, I have a huge chain of demands I keep track of, and methods of automation in order to collectively manage a constant flow of data requirements, and of course tracking issues both shared and common between these scenarios.

When I'm coding, I've got to code in a way that communicates these details to myself, consistent between all the languages I might have to touch for coding, scripting, database, reporting, and specialized languages a client may suddenly require.

Because of that, my code has to be a loose framework, a late-binding train station of logic, where demands may switch at any moment, and limitations imposed from other teams may similarly pop up.

My code is littered with multi-paragraph discussions of a technology I once had to interact with (customers often switch back), large sections of functions commented out rather than deleted, and other 'bad' practices just to give me landmarks and a 'flavor' of what a customer is occasionally interested in, amidst a never-ending avalanche of context switching between products and customers.

I've redesigned these several systems from the ground floor once (they used to only handle a small fraction of the work, using an antiquated language), and am working with a team to do a better design... but it's been very difficult for a team of perfectionists to understand how to react to an unlimited flow of changing requirements. Fortunately, the code itself has been quite usable, and they're using the same languages, but no system can really handle these demands truly consistently - I'd call it NP ridiculous. It's basically the "mythical man month" writ live, where I've got to do my work, and train a team whose work process may never really be able to do what I can do - definitely healthier long term, but can't help but result in some amazing process failures.

I actually would have made most of these design changes myself, but at the time, I was forbidden by management from making those choices, since I was doing my work directly at the production level - so it's actually a bit of a relief to see someone at least allowed to make some of the better choices.

In short (and yes, for this scenario, this is short), because I'm doing alone, for years, what a team of almost any size would struggle to approximate, as many of us seem to be doing, I've got no choice but to code how I need to in order to have a system that I can sanely maintain in an insane set of requirements. There's not really a choice in the matter, if your put in a position where "oh, we suddenly need this" exists as a live production task in a growing industry.

Ryan Fenton

Re:Readability wins every time

[R3d M3rcury]

Speaking of readability, here's an entertaining one I've been seeing more of in C:

if (result == SUCCESS)
versus
if (SUCCESS == result)

The rationale behind the second is that you don't end up accidentally assigning SUCCESS to result (eg, if (result = SUCCESS)). But I know that I find it weird to look at it the other way around. I want to know if the result was successful, not if successful was the result. Maybe it's an english thing.

I know that Xcode has been putting up warnings/errors for code that does assignments in if-statements and saying that if you really want to do that, wrap it in an extra layer of parentheses (eg, if ((booleanResult = Do_Something()))). I'm not sure this is somehow more clear that you're doing the assignment...

Re: Happy Saturday from The Golden Girls!

[Anonymous Coward]

Maybe because you are a douche?

Never - But Because Your Definition of Unnecessa..

[brian.stinar]

If you believe that code will help someone with understanding (yourself included) then it is necessary. It is needed to help with clarity. It may not be strictly required for the correctness of your program, but your goal should not be to express the correct solution as succinctly as possible. That approach leads to many other problems.

Occasionally I include solutions for problems which have not yet been uncovered. Those methods may not be called (dead code) and any kind of static analysis would report them as "unnecessary." If I make the decision that such code will help me, or help someone else, later then I believe it is totally necessary, and good to include. Worse-case is that it will be a good starting point for someone later, and they will throw it away and replace it with something better.

Never include unnecessary code. If there are incorrect implementations that you are replacing, remove the incorrect ones! Don't leave traps lying around for people to get caught in. Unexecuted code, or not succinct code, is not unnecessary. I constantly include semicolons, and brackets around one-line conditionals - those are defensive practices which are designed to prevent future problems, and aid in clarity.

This is why people are hiring you - to apply human intelligence and judgement to a problem. There are situations where doing not strictly necessary things is appropriate, and situations when doing not strictly necessary things is a waste of time. It's up to you to decide. Different actions are necessary for different metrics. One thing may be necessary for a correct solution, and another thing may be necessary to help someone else understand your correct solution. Everything should be useful (necessary?) under some kind of metric.

Re:Almost never

[BlackHawk-666]

Any c++ programmer with more than 1 years experience will see this immediately and slap some braces around it. Thanks to modern IDEs and standard indentation (which the IDE will auto-correct) it's extremely unlikely anyone will make this mistake, or it will go unseen for very long.

I'd group this sort of 'error prevention' in the same category as putting the constant first in every if statement e.g.

if (1 == YouShouldHaveDoneThisTheOtherWay)
{
        Whatever();
}

The people who make the mistakes that this shit prevents have no place working on code.

Re:Money

[Immerman]

/*
That's
fine
,
good
code
should
be
well
commented
*/