There are several signs that make my shoulders sag if I see them when I start working at a new site. These are the obvious errors that there is really no excuse for. If you’re guilty of any of these in your code it’s time to hang your head in shame, pull your finger out and stop it now!

1. EX006028E

This is the error that goes something like

Array arrayVariableName: subscript of 1 exceeds the current size of the growing array of 0 in a formula/rule (object_Name).

There is no excuse for ignoring this error, it isn’t a hard one to fix and you don’t just ignore error messages do you?

To eliminate this all you need to do is add some code to check that the array element you’re referencing is populated before you access it e.g.

IF index <= COUNT(arrayVariableName) THEN
  // do something with arrayVariableName(index)
ELSE
  // raise an error if it should be populated or just move on if it's optional
ENDIF

2. Text boxes named "text"

Or table objects named "table", "table 2" etc. Seriously? Is it so hard to click on the object name in the outline viewer and rename it to something meaningful? It may seem trivial but as applications grow in complexity you'll appreciate the difference between an error message that says

Array variableName: subscript of 1 exceeds the current size of the growing array of 0 in a formula/rule (MeaningfulObjectName).

Rather than

Array variableName: subscript of 1 exceeds the current size of the growing array of 0 in a formula/rule (table 2).

3. Blank Design Strings

There is no excuse not to populate the Design String property of variables, having sample data in variables can make a huge difference in terms of ensuring content is going to fit, and also makes identifying incorrectly placed variable easier to spot. Come on people, this is a feature that makes design easier so why not use it?

4. Typo's in specifications

Seriously this one drives me up the wall. If you can't take the time to spell check / proof read your technical documents, how much confidence should others have in your code? Take the time to run spell check, then proof read your documents to ensure they make sense. Really I shouldn't have to say this but I've seen far too many shoddy spec's to leave it out.

5. No documentation

Yeah I saved the best for last. This is one drum I can bang on all day long. I'm not saying you need pages and pages of documentation, the amount of documentation you need will vary according to business practices (for example, are you a quality at all costs organisation or deliver quick and fix in live) but no matter what kind of organisation you are, if it takes contractors and/or new staff over half a day just to work out which objects need to be updated then you don't have enough. HP Exstream and other tools are good at self documenting, but they only document the "what" not the "why" and this can be crucial.

So that's my top 5, I've probably missed some, so check for updates, but what do you think? Are you guilty of any of these? Am I wrong? I'd love to hear what think so post your comments below 😀