This is the fourth of a five part series on system design, relying on my own experiences and knowledge from working both in the public and private sector.

I have broken down my thoughts on system design into five distinct pieces: user requirements; development standards; usability, code-cutting (this article), and testing and go-live.

Code should be clear and understandable

In my current development environment, we don’t use naming conventions for variables, object names and the like, because we considered the standards-based questions:

• What do we need to do to fix this system?
• How long will it take to fix this system?
• How much will it cost to fix this site?
• How likely is it someone will have a problem with this system?
• What are the potential consequences if someone has a problem with this system

…with “naming conventions” in mind, and decided that while some sort of naming conventions were desirable, they weren’t sufficiently important in our environment to prevent something from going live or to ask it to be re-written.

What we do look for is that per project, each developer codes meaningfully and consistently.

In other words, it doesn’t matter whether you want to use t, t_, txt or txt_ as a prefix for text boxes; what is important is that whichever one you decide to use, you use it consistently across your application, and even more importantly that you give your objects and variables meaningful names.

txtFirstname is meaningful; you don’t need to compare this with the on-screen label to guess that it refers to someone’s firstname. Even if txt4 does refer to the fourth field on the screen, it’s not particularly meaningful: it would be of much greater benefit to know what that item represents.

Similarly, if you have a particularly long or complex piece of code, break it up with some brief comments to explain what you’re doing.

For example, I recently reviewed a piece of code I wrote a while ago that carries out a search function contains 75 lines of visual basic, 11 lines of which are comments. I have used the comments to identify each little block of code and explain either what it is doing, or what circumstances have lead us to this particular block of code:

• 'page is valid - Find matching events
• 'Step 1 - create basic SQL command
• 'Step 2 - determine criteria
• 'need to include name
• 'need to include date range
• 'need to include location
• 'need to include event type
• 'Step 3 - stitch together command and criteria
• 'Step 4 - find records
• 'these are the records that have been found
• 'no records have been found

Not only does this mean that if someone else has to amend my code later on it will be easier for them to see which bits are doing what, it is also considerably easier for me to come back to the code at a later date and work out what it’s doing!

On top of that, bear in mind that the variables and objects being used have meaningful names and it’s easy to track what is going on. It also makes debugging and problem-solving much easier too.

Coding in this manner makes your own life easier, and that’s something every developer ought to be in favour of!

Don’t Do The Same Thing More Than Twice

Some people use a stricter version of this rule: that they shouldn’t type the same piece of code twice, but by then ought to have written a re-usable function that they can call as circumstances dictate.

I’m not quite as obsessed about it as this, but I’m firmly behind making my own life easier, so if I find I’m typing out the same sorts of thing repeatedly, I’m going to try and find an easier way to do it.

As a rule of thumb if I find I’m going to have to write out pretty much the same lines of code for a third time, I will look to write a subroutine or function that can be called to repeat the procedure instead.

I usually make third time the charm because frequently this sort of thing will require parameterisation, so it’s just as onerous to write it out as a single parameterised function as it is to write out each line twice, but really the code would be neater and more elegant if this was done every time you need to use a specific function (or set of functions) more than once.

Parameterise Things

Following on from the last point, you can save yourself an awful lot of time if you parameterise things. Imagine you’re asked to produce a report from your database of all of the items currently in stock that cost less than £2.99.

You’ve got two choices: either you can spend a bit more time up-front creating a screen where the users input their search criteria and then you return all of the item details which meet those criteria (in/out of stock, minimum price, maximum price, warehouse etc), or you quickly knock up a single report for the ones less than £2.99, and then a week later you need to do another report for the ones less than £4.99, and then after that you get asked what items are currently in stock which we’ve not used any of in the last three months…

If you parameterise your queries at the outset (making sure not to allow SQL injection attacks into your database), you’ll save yourself work in the long run, because your users can answer their own queries by adjusting their criteria, rather than requiring you or one of your development team to write them a new report each time…

Use Whitespace

Feel free to use whitespace to ensure that the source code of your pages or forms is laid out neatly. Yes, in environments where your source code is not compiled prior to being served to the users (for example any HTML pages), this will result in your pages being a few bytes larger than they actually need to be, but the flip side of this is that your code will be much easier to track and maintain; and that is a price well worth paying in most circumstances.

Templates

Most development platforms and environments will offer some sort of opportunity to use a template. The use of templates is A Good Thing as this will help ensure that while different developers have a different development style, different preferences and so on, it will help keep them in the same ballpark.

How easy it is to use templates depends on your development environment: in Microsoft Access developments, my experience is that a development team will have a ‘standard’ database with various built-in functions and styles, which they will then take a copy of and customise according to preference.

Similarly, when developing in a .NET environment, I have created my own templates (although here they are called ‘Master Pages’) which can be incorporated into new web developments (with different forms of the template suitable for intranet or internet sites).

Possibly the most flexible templates however are those found in Adobe (formerly Macromedia) Dreamweaver, which offers quite a neat template function for web designs: you build your template and attach pages to it. When you make an amendment to your template later it can automatically search through the pages in your site which are attached to that template and apply the changes you have made.

Nice.

Of course, any web-based designs which have been done using properly structured HTML and CSS gain a number of the benefits of using templates anyway, because of course any changes to your CSS rules — assuming that you’ve used a linked stylesheet instead of inline styles — can be immediately applied across multiple HTML pages.

But of course you knew all that anyway, didn’t you?