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

You're the problem

[U2xhc2hkb3QgU3Vja3M]

If you think it's nice to break habits or do unconventional code just for the thrill of it, remember how fun it is when you need to work on someone else's code.

"The code comes out cleaner"?

[PacoSuarez]

If the code comes out cleaner, you didn't break any of my rules. The rule "make the code as clean as possible" trumps all other rules.

Re:"The code comes out cleaner"?

[EllisDees]

Does it trump the "make the code work" rule?

Re:"The code comes out cleaner"?

[Mikkeles]

Ah, the "No True Clean Code" fallacy.

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.

It's a tradeoff

[plover]

Sure, you can trade maintainability for efficiency and reliability. People do it all the time. You just have to understand the costs involved. If the efficient code gains you a million dollars in performance, maybe you can afford for it to be crappy code. Or maybe you'll be running the code for 10 years, and if it costs you $250,000 to keep a crusty old engineer on staff who can maintain it, suddenly that million dollars in performance may not be worth it.

<disclaimer>I am a crusty old engineer.</disclaimer>

Documentation

[PvtVoid]

From TFA:

my friend wired together an Eliza-like AI to his editor, and voilà, every function had a few lines of "documentation." The boss wasn't smart enough to understand that the lines meant nothing, so my friend was off the hook. His code was officially documented. I think he even got a promotion!

He should have been shot.

Re:Documentation

[amicusNYCL]

The boss or the developer?

Yes.

long methods and coupling

[Anonymous Coward]

long methods - someone thought it a good idea to limit every method to no more than 20 lines. I think this is a terrible idea, and can make code unreadable, which leads to:
coupling - it's often best to tightly couple things for ease of debugging and development. How often are you going to change the database you're using? Is it worth going through another abstraction for every database call? Too much abstraction makes code unwieldy.

I'd rather have a bunch of 200 line methods that represent logical units of work than a call stack 20 layers deep.

Dijkstra Nailed It

[myrdos2]

In short, I suggest that the programmer should continue to understand what he is doing, that his growing product remains firmly within his intellectual grip. It is my sad experience that this suggestion is repulsive to the average experienced programmer, who clearly derives a major part of his professional excitement from not quite understanding what he is doing. In this streamlined age, one of our most undernourished psychological needs is the craving for Black Magic and apparently the automatic computer can satisfy this need for the professional software engineer, who is secretly enthralled by the gigantic risks he takes in his daring irresponsibility. For his frustrations I have no remedy......

--Edsger W. Dijkstra

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:Lessons

[internerdj]

"Think of newspaper headlines when commenting. Don't make somebody read the whole article to know what the article is about." You_won_t_believe_the_three_things_this_method_does(), This_method_just_announced_it_was_running_for_the_GOP_presidential_nomination(unsigned int year), Five_ways_to_make_your_integers_long(), ...