When I started my Information Processing and Technology (IPT) subject in Year 11 at school way back in 1991 one of the first concepts that the teacher, Mr Whitehouse, impressed upon us was to avoid writing what he called "spaghetti code". What he meant by that term is the kind of code you end up with if you just sit down and start hacking away without giving any real thought to the best way to address the issue.

Of course, in the real world, you are faced with time constraints and sometimes you need to get something created or fixed in a hurry so it can be very tempting to just hack out a solution and move on to the next problem. Where this can become a problem is if someone has to go back to your fix and improve on it or add to it. If the fix is not a logical solution or does not lend itself to being easily modified or maintained then you have just created more work with your fix in the long run.

I have been reminded of this recently when working with a site and code we've been asked to fix and found code that has been prefaced with comments saying things like:

  // HACKHACK - We should probably use a named keyword instead of a magic numbers

I have always tried to approach such issues by doing it the right way in the first place rather than coding a "hack" and then pointing out to subsequent programmers that it is a hack. The problem, in this example, will arise when someone goes back to the code and has no idea what the magic number is supposed to represent whereas, if a constant was used instead, the name of the constant would provide a clue.

Another situation where I have encountered this hacking mentality is in situations where raw SQL queries have been included in scripts. We always use object oriented programming structures and part of this includes abstracting the raw data access away from the high level requirements such as "I want the member with name John". I think it is important to do this not least of all because it makes it a lot easier to make structural changes to database tables if all references directly to the table are stored in one place.

This is where the maintainability of your code becomes an issue. Obviously, there is a larger overhead in doing things correctly in the first place. It takes more time to create a constant rather than using a magic number or to create or modify an object to allow for a new function or method of accessing the data. However, I think it is preferable to do thing the right way the first time because it might be you coming back six months later and looking at the code and trying to figure out what the hell you were thinking about when you did that hack or why has changing this property in the database suddenly broken the whole site?