Good Programming Practices: What to Do (or Not)



Formatting Your Code
Why style matters

Universal Programmers Toolkit
Care and feeding of your code collection

Effective Proactive Debugging Techniques
It's all about the tools

Good Programming Practices
What to do (or not)

Banning Bad Bots
A short but effective script


The Joy of Specs
How to (almost) guarantee a successful project

Habits of Successful Freelancers
Advice for success

How to Become a Great Programmer
One easy lesson!

Bidding on a Stranger's Project
The basics

Freelancing 101 - Don't Send That Email!
Pick up the phone instead

Ensuring Your Web Site Project Succeeds
Advice for clients


How to Take Great Photos (And Fix Lousy Ones), Part 1
Composing and shooting your photos

How to Take Great Photos (And Fix Lousy Ones), Part 2
Editing and postproduction

Good Programming Practices: What to Do (Or Not!)


Most programmers suck. No, I'm not trolling or being glib. I'm simply stating what I've concluded after updating countless other people's code over the years. In fact, statistically speaking, chances are your code sucks. Don't believe me? Here is a list of good programming habits that most people would agree are Good Things in principle, yet precious few adhere to in practice:

There's nothing worse than comments complaining about something unrelated to the code, especially when the code is poorly written to begin with. Make sure your house is clean before complaining about other people's houses.

If you want to go all the way and do the right thing, you'll actually document your code as well. That means writing a separate document (not comments in the code) that goes into more details on the operation and function of your code.

connect_to_database(...) or die("Unable to connect to DB!");

This type of error handling is:


No programmer can ever implement all of these suggestions 100% of the time. Not only does one reach a point of diminishing returns, but also there will always be areas that are open to interpretation, opinion, and individual style.

But just because perfection isn't achievable doesn't mean you shouldn't strive for it. In fact, the most important thing you can do is to identify the area(s) listed above where your program is most lacking and take steps to fix it. For example, your program might have excellent database handling routines but your variable names may be completely unintuitive.

Half the battle is figuring out (and admitting) where your program needs improvement; the other half of the battle is doing something about it.


Return to Kim Moser's Generic Home Page.
Copyright © 2023 by Kim Moser (email)
Last modified: Tue 10 May 2022 12:08:05