Cannons 2000 Revisited
Saturday, May 10, 2008
This article was originally on devblog.coobird.net.
As a Saturday morning project, I took the first serious look at Coobird’s Cannons 2000 for the first time since 2003. The program is listed as one of the programs I’ve worked on in the past in the Past Programs page at coobird.net.
Cannons 2000 was originally written back in 2000, as the title may suggest (and also is a testament to how “2000” was really a suggestive of how futuristic something is, at least back in the 20th century.) and it was written in QuickBASIC 4.5.
This morning and the early afternoon (a total of about 3 hours) was a session in cleaning up the source code a little bit. Looking back at work written back several years ago, it was quite embarrassing. It was plagued with:
-
Unindented code – The entire codebase (only a thousand lines or so?) was unindented and very difficult to read.
-
Lots of
GOTO
s andGOSUB
s – although it appears that I was using subroutines and functions for certain aspects, it didn’t really look like I really knew what the heck I was doing. Although some parts used functions and their returns in meaningful ways and subroutines were written where they were called without using GOSUBs, some parts were littered withGOTO
s andGOSUB
s. Spaghetti code at its best. -
Poorly names variables (and functions and subroutines) – Variables like
py%
,setd
,inv1
,inv2
were all over the place. The functions and subroutines were just as bad with very descriptive names such asboom
,boom2
,splode
, etc. -
No understanding of multi-dimensional arrays – There were some arrays being used, but when they required have two dimensions (e.g. a situation where each player requiring their own array for their inventory), they were using the variables
inv1
andinv2
, where it would have been best using a two-dimensional array. -
GOTO
s being used for loops – Loops where keyboard input from the user is being polled were inGOTO
loops, where aDO
loop would suffice. Although there were some cases where I did notice how BASIC has its deficiencies. If BASIC had a facility to skip one iteration of aFOR
loop, like thecontinue
keyword in Java, it wouldn’t require a jump to a label next to theNEXT
statement of aFOR
loop. -
Copy-and-paste redundancy – Sections of code were copy-and-pasted in different parts of the program. One example was a section where two players buys weapons to use in the game. Each player had their own menu display along with keyboard input code. One of them was removed and one was kept with a
FOR
loop around it to run through each player. And subroutines with essentially the same content, but different magic numbers…
Although not all of the problems has been addressed through the code clean up, such as poor variable names and some of the redundant code (especially the subroutines which were part of what I would describe as “spaghetti logic” due to the logic being designed like spaghetti), the code was indented and the subroutine and function names have been cleaned up.
However, the GOTO
and GOSUB
spaghetti remains, as it would require quite a bit of effort (reorganizing the code) to clean up.
Overall, taking a look at work from the past made myself realize how awful I was writing code back a several years ago. But it’s also been a good refresher on BASIC and a good reflection on how I have been able to write better code today. (But then again, when I look at code from a year ago, there are quite a few places where I’d go “why the heck did I do that?” so programming definitely is a subject where growth happens everyday.)