Bad Programming Habits We Secretly Love (infoworld.com)

snydeq writes: Breaking the rules can bring a little thrill — and sometimes produce better, more efficient code. From the article: 'The rules are more often guidelines or stylistic suggestions, not hard-and-fast rules that must be obeyed or code death will follow. Sure, your code might be ridiculed, possibly even publicly, but the fact that you're bucking conventions adds a little bit of the thrill to subverting, even inadvertently, what amounts more often than not to the social mores of pleasant code. To make matters more complex, sometimes it's better to break the rules. (Shhhh!) The code comes out cleaner. It may even be faster and simpler.' What bad programming habits can't you (or won't you) break?

Comments

GOTOs in C

[Anonymous Coward]

I often use GOTO statements in C code to mimic exception catching without duplicating cleanup code. It works very well, and its easy to understand, maintain, and debug. Example:

x = do_stuff();
if (x 0) { goto cleanup; }

y = do_more stuff();
if (y 0) { goto cleanup; }
return 1;

cleanup:
fix_my_mess();
fix_it_4realz();
return 0;

Re:GOTOs in C

[halivar]

Comp Sci professors teach "goto = bad" because the wisdom necessary to use it competently comes only with experience. It's like jazz; you have to know the rules and follow them before you can break them and not sound like a jack-ass.

Re:GOTOs in C

[PRMan]

void cleanup()
{
fix_my_mess();
fix_it_4realz();
}
...
x = do_stuff();
if (x == 0){
cleanup();
return 0;
}

y = do_more_stuff();
if (y == 0){
cleanup();
return 1;
}
return 0;

Lessons

[Tablizer]

Variable and object naming, and commenting is an art-form that takes experience to do well. Here's a few practical guidelines I've learned follow:

1. Think of newspaper headlines when commenting. Don't make somebody read the whole article to know what the article is about.

2. Comment the "odd" stuff, not the obvious stuff infer-able from function name etc.

3. Goldilocks Rule: Names both too long and too short can be bad.

4. The more frequent a name is used, the shorter it should be. Use comments at declaration to give the full name. Example of a variable that may be used often:

var dhv_id; // Department of Housing vendor ID

If it's used often, I'd rather have an abbreviation than see DeptOfHousingVendorID all over the code, making it long and "wrappy".

5. Everybody has their own preference, but you have to target the "average" developer (future unknown reader) to make code future-friendly.

Re:Copy and Paste.

[PRMan]

But continue is very clear, as is break and return. Goto could go anywhere in theory, so it slows you down as you scan around looking for it.

Re:You're the problem

[Anonymous Coward]

This. It's not about YOUR code, it's about the poor beggar who gets to try and debug it at 3am when it breaks. After it's been maintained for 3 years. By hordes of other programmers with indeterminate skills, most of whom took their stylistic cues from you. And still has your name all over it.

There are very few circumstances under which a marginal boost in efficiency is preferable to code that's easy to maintain. Stylistic rules are there for reasons - and "efficiency" isn't one of them.

Re:"The code comes out cleaner"?

[aix tom]

Having "taking over" a lot of code in my time, I can say for myself, having code that "works and I don't know why" makes me more nervous that code that "doesn't work and I don't know why".

I'd rather have clean code, be it working or non working. If it's clean I can get it to work reasonably quick. If it's not clean and not working then I can easily justify a re-write. But if I can't understand it and it seems to be working, I always have the dread that someday it will break in a disastrous fashion in the most inconvenient of times with me being unable to do anything about it.

Re:You're the problem

[Anonymous Coward]

Used judiciously, a goto can save a lot of trouble. The three use cases I have for occasionally using a goto are to break from nested loops, to break from a switch-case within a loop, or as part of error-handling routine where an exception-based approach are not possible or not permitted. In all cases, these are within the scope of a single function.

Re:Documentation

[jeremyp]

The functionality of a non private API must be documented. Requiring people to read the code in a function in order to find out what it is supposed to do is stupid.

If a programmer changes the code in a function such that its API documentation is wrong, the documentation hasn't gone stale, the programmer introduced a bug.

Re:You're the problem

[AmiMoJo]

We had a contractor I'll call Paul. He wrote exactly to spec, and not a line more. If you didn't say "protect against buffer overflows when accepting user input" you can guarantee his code would crash if you input a single extra character beyond the prescribed format. It only worked if you did exactly what the user manual described. Any slight deviation and you were screwed, often in ways that were not immediately obvious.