How to Keep Your Code From Destroying You

An anonymous reader writes "IBM DeveloperWorks has a few quick tips on how to write maintainable code that won't leech your most valuable resource — time. These six tips on how to write maintainable code are guaranteed to save you time and frustration: one minute spent writing comments can save you an hour of anguish. Bad code gets written all the time. But it doesn't have to be that way. Its time to ask yourself if its time for you to convert to the clean code religion."

Comments

Who wrote that article?

[Anonymous Coward]

Captain Obvious?

Re:Who wrote that article?

[dvice_null]

I think all Slashdot readers should read that article. After all it tells you how to write good _comments_.

Re:Who wrote that article?

[Bravoc]

Cool!

Write an article, anonymously post it to /. in the form of a review, get a billion hits. "Look boss, my article is so popular, it got a billion hits!"

Demand raise for being a popular columnist

I gotta remember that one.....

Damn

[ReidMaynard]

Damn, that game looks sweet. Anyone know what it is?

In Soviet Russia

[quarrelinastraw]

In Soviet Russia, code destroys YOU!

Expected Value

[dcollins]

"One minute spent writing comments can save you an hour of anguish."

However, what's the probability that the savings actually goes to *you* and not a coworker competing with you for a promotion, or someone who replaced you in a later year? If you work in an office with 100 staff, let's say 1%. So expected savings to you is EV = 1% x 60 minutes = 0.6 minute, less than the minute it takes to write the comment. (Even assuming the payoff is correct, and then helping competing coworkers doesn't do any damage to you.)

This is what I consider to be the "tragedy of the commons" for software engineering jobs. When I was a programmer, the people who did the least documentation were the fastest, and often the only folks who could approach certain parts of code, and so held in the highest esteem by the executives. Now I only write code for my own projects.

At this point I am thinking

[dfuhry]

Wow. That was a big waste of time. All of this stuff is obvious and everyone knows it. Why did anyone write all of this?

Actually

[Dachannien]

Actually, it's not necessarily a bad thing for your code to destroy you. Just make sure you don't dereference any old pointers to you afterwards.

But C doesn't have classes or methods.

[wiredog]

It has functions...

If I understand correctly

[Ambitwistor]

To keep my code from destroying me, I shouldn't #define MAX_ALIENS_ON_SCREEN_AT_ONCE to equal 100. That's way too many aliens to survive.

Steps for Job Security

[Mr Pippin]

Yep, no you need to include the "Back To School" basic programming techniques, like Rodney Dangerfield might include.

1. Use comment syntax to obfuscate the actual running code
2. Don't indent or "pretty format" your code
3. Use the same variable name over and over, capitalizing different letters to make them unique throughout the program
4. Use variable names that are incredibly offensive in hindu, so any common "outsource" programmer will refuse to work on the code.
You get the point.

Re:Self documenting code?

[Lord Bitman]

except friday.. I want to go home. I'll clean it up on monday.

Noooooooooo

[Anonymous Coward]

In Soviet Russia, Code comments YOU!

Re:The whole article is -1 redundant.

[jstretch78]

I agree, but could all those hours of puzzling actually improve your ability to understand poorly written code? I've been using comments sparsely for years and have spent much time fustrated. But I've found that I can 'See the Code' like on the Matrix and bend spoons and shit.

Two rules to live by

[kabdib]

Rule #1 of Systems Programming: Never check for an error you don't know how to handle.

But, if you simply MUST, then:

Rule #2: If you have to blow up, arrange it to be in someone else's code.

That way, when you're (say) deep in your file system update locking and you realize that something's gone truly plonkered, you stealthily return something that causes X Windows to blow chunks long after you've returned.

"It's the file system."

"No, it's not. It's the bloody clipping code in X. Remember when release 10.5.08A came out? It's just gotten worse from that. Did I ever tell you about the time that 9.02 was released? Let me just say, you're lucky, man . . ."

Rule #3: When necessary, distract, distract, distract. Everything is on the table, and "Look, the Goodyear Blimp!" [points excitedly] is just for starters...

Good systems programmers know these tricks, and all the others you haven't learned about yet, which is why they're curmudgeons with level 70 pallies and tier-2 gear and you're shovelling Java and XML around trying to make a rent check.

Cheers!

Simple really

[riskeetee]

Don't deploy your code to the ED-209.

Simple Enough

[vimh42]

First of all. Don't write a program called MCP. Second, don't work for a company called Skynet.

What did we do to deserve our time wasted this way

[Livius]

No, this has to come from no less than Field Marshall Obvious.

"Comment like a smart person."

Let's all "program like good programmers" while we're at it, or, even better, "invest like lucky investors", "dance like a professional", "socilize like an extrovert", "copulate like leporids", "wield power like a super-villan", and "fly like Superman".

Besides, nice idea in principle, but based on two grievously flawed assumptions: the programmer is a smart person, or at least knows what one is like, and the next programmer reading it will be a smart person.