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

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.

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:"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.