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.
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.
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.
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.
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.
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.
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.