Bad coding habits.  I have blogged about this before. The bain of nerd-existence.  The land of laziness. The hallmark of half-assitude. The sign of ineptitudeness, or ineptness, er, ineptiness, or, uhhh, whatever.

So why am I regurgitating this now? Because I’m not seeing much improvement. Most programmers today seem to pay more attention to the quality and consistency of their boogers than they do on their code work. It scares me to think “attention to detail” is slipping out of fashion.

It’s one thing when youngsters make mistakes. But when I see sample code posted on vendor web sites by their own staff, it falls under a more powerful microscope. Especially big-name vendors. And when that kind of sample code falls below best practices 101-level rules, it’s time for a waterboarding. Maybe even a William Wallace draw-and-quartering. Too soon?

Take a look at the following horror. Don’t stare at it too long or your eyeballs will detach and run for the nearest bus stop. But just gaze at the train wreck and count the bodies for a second…

cityName = "Anytown"
If cityname="anytown" Then
  wscript.echo "this code is tragically bad."
  wscript.echo "the author should be " & _
  "tasered in the crotch repeatedly " & _
  "until they adopt better habits!"
  wscript.echo "If I don't care enough " & _
  "about the little stuff, I am not " & _
  "worthy of playing the role of a " & _
  "scented urinal puck in the restroom " & _
  "of a bus station."
end IF

Are thinking, “thats not so bad. Whats the big deal?” Well, technically it is a small chunk of code in an arcane language (stop snickering please). But if the wheels are coming off the cart in the first three feet of the ride, Houston as a bigger problem ahead. Now, take off more points for having something like this reviewed, approved, and posted on a Fortune 500 company web site. Yeah. Time to load the shotgun and go nerd hunting.

If you don’t see the bodies you’re not a coder. Not a script monkey, code jockey, key smacker, compiler defiler, debugger unplugger. None of that. But that’s okay too. Not everyone has to be defective. Someone’s got use the stuff after all. And yes, some of those names are made up.

This isn’t even about logic or statement optimization or factoring efficiency. It’s not about debating evaluated conditions versus static comparisons. Dynamic constructs, imperatives or declaritives. Nope. None of those big words. It’s about paying attention to the little stuff so your eyes and brain are tuned to better catch the bigger stuff.

The language matters not.  Seriously. It doesn’t matter. Whether it’s Perl or PowerShell. SQL or JQuery. Ruby, Java or C#. What matters is caring about what you do, and how the results look.

So, what then?

Here are some really simple rules that might save you from my vengeful wrath, once I win the lottery and get my Lord of the Universe kit (complete with titanium shell propellor beanie cap and laser-guided bong rocket). Because once I get that kit, and strap on my bong rocket, I’m vaporizing anyone I see writing crappy code. And just so you’ll be prepared, my bong rocket will spray flaming Ebola mist, mixed with napalm and horse dung, and it’ll play Justin Bieber tunes really loud. I have ear plugs.

Ready? Here they are:

  2. Modularize your code.
  3. Document your code.
  4. Externalize references.
  5. Always Code for Stage Review

What do all these mean?  Here goes (loooooooooooooooooonnnnnnnnnnggggg inhale.   hold it…. hold it…….. hoooollllllllld it….. and…)

Consistency is king!  Period.  Do it one way.  Capitalization.  Punctuation. Indentation.  Naming conventions.  Scoping. Factoring.  Refactoring.  Defactoring.  Jaw-jackering. Monday morning quarterbackering. Whatever.

Pick a consistent approach and follow it.  Mixed code habits tell me one thing:  You don’t care enough about the little stuff, so I can’t trust you for the bigger stuff.  Casual approaches to coding habits are what lead to things like space shuttles blowing up and bank accounts getting hijacked.  Not good.  Don’t do it.

Modular coding is easier than you think.  Many new (aka noob, noobish, or noobatastic) coders think that “modular” is a big word to avoid and make snickering chuckles and snears.  Tee-hee.  Shut up!  Imagine if your car shoved everything that had anything to do with the engine into the engine block itself.  All of it. Dashboard too. Yeah.  It would look like a garbage disposal.  Tragic, just tragic.  

Separate your code into little black-box chunks.  Don’t be afraid to make and use functions.  Functions are your friend.  Functions will be there when you need them.  When you’ve had too much to drink and your buddies dump you in a Walmart without your pants.  Functions will be there.

Document. Yes, document the $$$$-ing $$$$ out of your $$$$-ing code. How much is enough? Just keep documenting and I’ll let you know when you can stop. That’s like asking how much sex or beer or Count Chocula is enough. Silly coder.

There is no one-size-fits-all rule when it comes to code documentation. It depends on how complicated the work being accomplished is. I’ve seen some code for 3D modeling and kinetics analysis where the documentation was 3 times the actual code. And that was abbreviated wording.

One tip I was given, that I still use, is to imagine you’re explaining to the dumbest person on Earth what each part of the code is doing. That dumbest person is you, six months from now; when you have to dive back in to change sonething and you can’t remember even writing it.

Externalize. What I’m talking about here is pulling environment conditions. But I’m also talking about using external resources and capabilities when they’re practical.

Examples? Don’t hard-code the hostname if you can query for it. Don’t make an elaborate string-parsed dictionary to sort a shitload of records when you can invoke a disconnected record set in half the lines and it’ll execute three times as fast. Shitload is a technical term by the way.

Code for Stage Review. Ever have something you turned in back in grade school that was shown to the entire student body unexpectedly? Remember that “oh shit. I hope I didn’t forget something obvious” feeling?

Write your code as if it’s going to be reviewed at TechEd in front of live and internet viewers. As if the people who write the books you bought are going to grade it.

So does this eventually turn you into a perfect coder? Not really. But it’ll turn you into a careful coder. And a careful coder is a quality coder. And people who know and care about quality willingly pay more to get quality people to provide quality services. And best of all: all of this is entirely your own doing. Own it.

Over and out.


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s