A quick introduction to this category of posts before I get to the meat of the issue. Over the years during which I’ve made my living writing computer code, I’ve uncovered, discovered, created or outright stolen several aphorisms about writing good code. In keeping with the arrogance that comes with being a computer programmer, I gave them the grandiose name Bull’s Laws of Software Development. Most of them aren’t really laws, just personal guidelines or humorous little sayings. Please do not cite them in a court of law. That would not go well for you.
One more quick note. I don’t know exactly how many laws there are, and every time I reference a law, I arbitrarily assign it a new number. (Please see my forthcoming* post on the impact of arbitrary numbering schemes on the efficacy of humor.)
Okay, enough dilly-dallying. Let’s get on to Bull’s Law of Software Development #37: The Single-Character Rule.
Put simply it goes like this: The longer you spend unsuccessfully attempting to fix a bug (or issue or what have you) in your code, the greater the chance that it’s caused by a single errant character.
I cannot tell you how many times I’ve been bitten by this. (Not because I don’t know the number but because thinking of the number makes me want to cry.) Semicolons in particular have wasted many hours of my life. A single missing curly brace can turn a finely-tuned piece of code into a steaming mess of compiler errors faster than a horde of programmers can demolish a pizza buffet.
I know some people will think this is blindingly obvious, along the lines of “it’s always the last place you look”, but this is the first Law I ever came up with, and still the one that comes up the most often. And I have occasionally found it to be a useful reminder. When I’ve been staring at the same code for an hour and can’t figure out what’s wrong, I think of this rule. It prompts me to take a break, walk away from the problem for a few minutes, and then come back to look at it from a fresh angle, thinking mostly of where that one character is (or isn’t). More often than not, I can spot the problem right away.
If any non-programmer type person has made it this far into this post, hopefully there’s a little nugget of wisdom that can be applied to other problems. Aaaawwww, who am I kidding, it’s just us nerds down here. Might as well indulge in some real nerd speak, then.
Can you believe the specs on the new Ramostat Quadthruster? Like anyone really needs a six-core multiprocessor on a Quadthrusting hyper-flangle. Am I right, nerds?
Nerds?
Man, now it’s just me.
(sigh)
* And by “forthcoming” I mean I will never write such a post.
Did you mean = or == ?
That one has caught me quite a few times. If you’re trying to test equivalence the assignment operator (in most languages I’ve worked in) will resolve to true. The really sneaky one is ===, though. 🙂
The corollary to this is my “Developer’s Law of Threes”, to wit:
When you find a bug, try to fix it.
If the first fix fails, by all means, try again.
If the second fix fails, step away, re-think and take one more stab at it.
If, by now, you have not resolved the issue…. STOP! Leave! Back away from the keyboard and seek help. (Where to find help is situationally dependent)
I’ve seen dozens of skilled developers code themselves stupid trying to fix the same problem for the n-teenth time. Getting another set of eyes on the issue is much more effective.
I understand this post now!