Cannons 2000 Revisited

Saturday, May 10, 2008

This article was originally on devblog.coobird.net.

Cannons 2000 image

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:

  1. Unindented code – The entire codebase (only a thousand lines or so?) was unindented and very difficult to read.

  2. Lots of GOTOs and GOSUBs – 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 with GOTOs and GOSUBs. Spaghetti code at its best.

  3. 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 as boom, boom2, splode, etc.

  4. 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 and inv2, where it would have been best using a two-dimensional array.

  5. GOTOs being used for loops – Loops where keyboard input from the user is being polled were in GOTO loops, where a DO 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 a FOR loop, like the continue keyword in Java, it wouldn’t require a jump to a label next to the NEXT statement of a FOR loop.

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