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
I completely agree about the comments bit.
The number of times I've looked at code and it's taken me 3 times as long to fix because the comments are so bad (or there aren't any at all).
The one thing I do though to keep myself happy is use strange variable names (which I know is bad form but I do DIM them with an explanation at the top of the page).
My current favourites are Dilbert, Dogbert, Ratbert, Catbert and PHB.
Sad, I know… :p
At least you give an explanation for them. My single letter variables used to crop up all over the place, and they were all globals as well. Sometimes I wonder how I managed to complete anything back then.
In my initial days, when i had little knowledge of how code compiles, i thought it would be faster to use math expressions rather than conditionals, thinking: "long code is slow code".
I managed to avoid most if statements by converting these into a long math expression. My favourite operations were Math.Round(), Math.Floor(), Math.Ceil(), Math.sqrt(), besides the traditional +-*/.
The disadvantage of this is twofold:
bunch of nested if statements with a single expression composed of alot of operations.
With if statements the code is alot longer, but the program execution goes through those statements very fast, like in a tree, taking log(n) time instead of the k*n operations of the math approach.
Now THAT is bad. :)