Five things I wish I’d known when I started programming
Halloween isn’t for a while, but it’s always a good time to read some coding horror stories.
I’ve been programming since I was able to use a keyboard, and it’s one of the best skills I ever learnt. Like any skill, it has to be constantly fine-tuned, and I’m always on the lookout for ways to improve. Here’s a few important things I’ve learnt over the years, most of them from my (very) early days.
1. “Funny” comments aren’t funny at all
The first large game I wrote was a text adventure for the Atari ST. Instead of commenting each section of code with something useful, they had “funny” comments instead. For example, the code that handled eating had a comment saying “Bite me” above it. How witty.
2. I suffer from Premature Optimisation
I always find it satisfying to squeeze a bit more speed out of any routine, but sometimes it’s difficult to wait until the code is actually functioning how it’s supposed to. Some of these optimisations can leave code very difficult to read, especially if they’re using functions I wouldn’t normally touch.
Naturally, I’d leave these obscure changes uncommented as a challenge to my future self.
3. The compiler doesn’t care how my code looks
Source code is for people to read, and compilers to translate. It really doesn’t care if my braces start on a new line or not, so I don’t worry about it. If the formatting of the code is a problem for me when I’m reading it, then I’ll change it.
Incidentally, I once read someone else’s source code that controlled a ball, and they’d arranged the code to look like a ball. I thought that was awesome, especially because it wasn’t an entry for the code obfuscation competition.
One of the few things I managed to get right in my early code is indentation. It’s one of the simplest changes you can make to any source file, and it really affects how readable things are.
4. Languages support comments for a reason
Somewhat similar to number 1. The only thing worse than looking at a source file and thinking “Why didn’t this idiot comment their code?” is realising that it’s yours.
Good commenting is an art form in itself, but it’s a highly valuable skill. Good comments explain why something is happening, not what is happening. Nowadays I use PDL as often as I can, and I find it makes code much more readable. Not only does it mean code is commented well, but it means I have to think about things before I start typing.
5. Use decent variable names
In BASIC, “$” often represents a string. I used to think it was funny to use the variable name G$. If I’d already used it, I might call it G2$, or even GG$. As you can probably imagine, anything that used more than about five variables turned into a completely unreadable mess.
I know I was young and reckless, but it’s no excuse for such horrible, horrible variable names.
Oh dear
So there we have it - a collection of some of the scariest code ever written. There’s plenty of other lessons I’ve learnt, such as “Use functions instead of copying and pasting code” and “Use good function names instead of ‘print2′ and ‘print3′ “, but these are the pick of the bunch. Sometimes you only realise how important some of these things are when you do them badly.
3 Comments