10 bad programming habits we secretly love
December 2, 2019
We’ve all done it: snagged a cookie when mom wasn’t looking, had a little too much wine for dinner, let the car sit in a parking spot after the meter expired. We’ve even gone around Deadman’s Curve a bit too fast. And yes, we’ve all violated any number of the cardinal rules of programming, the ones that everyone agrees are bad. And we secretly liked it.
We’ve thumbed our nose at the rules of good programming, typed out code that is totally bad—and we’ve lived. There were no lightning bolts from the programming gods. Our desktops didn’t explode. In fact, our code compiled and shipped, and the customers seemed happy enough.
That’s because bad programming isn’t in the same league as, say, licking an electric fence or pulling the tail of a tiger. Most of the time, it works out. The rules are more often guidelines or stylistic suggestions, not hard-and-fast directives 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 to (more often than not) 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. The rules are usually a bit too broad, and an artful programmer can improve the code by breaking them. Don’t tell your boss, but sometimes it makes sense to code your own way.
What follows is a list of nine rules that some may consider unimpeachable, but many of us break often, with both success and pleasure.
It’s wrong to do it in school. On the job, the rules are not so clear. There are certainly some blocks of code that shouldn’t be stolen. If it comes from proprietary code, don’t fold it into your stack, especially if it’s marked with a copyright message. Write your own version. It’s what they’re paying you to do.
The trickier question comes when the original creator wants to share. Perhaps it’s on one of those online programming fora. Perhaps it’s open source code with a license (BSD, MIT) that permits snagging a function or three. There’s no legal reason stopping you. And you’re paid to solve problems, not reinvent the wheel.
Most of the time, the advantages of copying are compelling and the disadvantages can be limited with a bit of care. The code you get from a reputable source has already had at least one round of thought applied to it. The original author searched for a solution and found something. The loop invariants and the data flow has been worked out.
The tricky questions are whether there are some unfound bugs or some different assumptions about the role or the underlying data. Perhaps your code mixes in null pointers while the original code never checked them. If you can fix the problems, it’s like your boss is getting the input from two...
What we do
Contact US
