Spelling and Software Quality

In Charles Dickens' Hard Times, the severe Mr Gradgrind teaches children “Facts. […] nothing but Facts. Facts alone are wanted in life”. In a similar vein I would like to teach computer programmers “Spelling, nothing but spelling. Correctly spelt words alone are wanted in computer programs”.

I may well be a pedantic, mean spirited, weasel coder of a man but badly spelt words in software code drives me crazy. There is more to it then my love of order, rules and finding any old stick to beat other coders with. Spelling mistakes in code have the half life of plutonium. If some one spells a word wrong in an email it doesn’t matter. It’s sent, it’s read and it’s gone in an ephemeral puff of cyber smoke. If someone spells a variable name wrong in code it will lay around in that app like a bad smell for years. And if some creature of great evilness spells a database table wrongly – the universe will undergo its final heat death before anyone gets round to correcting it.

It’s more evil still then just poor use of the English language offending me on a daily basis. It’s a software maintenance nightmare. At a minimum the poor maintenance coder has too remember exactly which variant of the word “category” is been used this time. At its worst seemly innocent typos cause redundant code to proliferate like rampant triffids.

As a recent example I came across are these stored procedures

usp_GetPersonelDetails
usp_GetPersonnelDetails

OK – which one is the correct one to use? Either, both, neither? Which one can I delete to tidy up? Which one is the most recent version? Which one will cause the app to fall into a smoking heap if used? Aaahhhhhhhh!!!!!!

So as well as unit tests, regression tests and usability tests, I prescribe spelling tests to push back the ever encroaching waters of crappy code.

It’s a BUG

The other day I was merrily exporting a SQL Report to Excel when I came across this cheeky little message where some tables should have been

"Data Regions within table/matrix cells are ignored"

A quick search on forums reveals the following solution

This is a known issue in the reporting services. It is caused by the limitation of the Excel rendering. So you may redesign the report or export to other formats.

Well that’s a relief. It’s not a bug it’s a known issue and limitation, entirely different from a bug. If it was a bug I’d be stuffed and would have to go back to my project manager and tell him that we’re starting the export again from scratch so the deadline is receding rapidly into the distance. Thankfully because it’s only a limitation I only need to go back to my project manager and tell him that we’re starting the export again from scratch and etc………..

IT’S A BUG. It’s not a limitation, known issue, user error, unforeseen circumstance or convergence of several highly unlikely events. Come on Microsoft admit to it. My software’s got bug’s, my colleagues software’s got bug’s and Microsoft’s software’s got bugs. It’s nothing to be ashamed of. The first step to solving a problem is admitting it’s there. Mr Bill Gates – you’ve got a bug.

Self Documenting Code – Gimme Just One Less Line

I was in a technical interview a good while back and it was review your answers to the tech quiz time.

INTERVIEWER: OK, that’s a good answer. That would work but can you do it in less lines of code
ME [chewing pen]: Errmmm –OK that’s it in two lines
INTERVIEWER: OK – but I’m sure you can do it in one line
ME [scratching head]: Oooooo – Errmmmm – that’s one line
INTERVIEWER: Well Gee – that does it. But I’m sure you can do it in maybe 10 characters
ME [Weeping real tears]: Ahhhhhhhh !!!!!! Please let me out.

OK – maybe the end of the interview went a bit better but I must have spent a good 20 minutes frantically trying to trim down my code to the size of an atom. I retrospect I think it was a fair enough way to grill me – but in the day to day work of chipping away at in the salt mines of computer code do you ever want to trim your code down to the bare minimum?

Consider this code

private static string RemoveTrailingTag(string input, string tag)
{
  if (input.Length >= tag.Length && input.Substring(input.Length - tag.Length) == tag)
    {
      input = input.Substring(0, input.Length - tag.Length);
    }
    return input;
}

OK – it’s trimming tags from strings. But what on earth is the 'if' statement doing. The revised code tells us

private static string RemoveTrailingTag(string input, string tag)
{
  if (HasTrailingTag(input, tag))
  {
    input = input.Substring(0, input.Length - tag.Length);
  }
  return input;
}

private static bool HasTrailingTag(string input, string tag)
{
  return input.Length >= tag.Length && input.Substring(input.Length - tag.Length) == tag;
}

OK – the ‘if’ checks for the trailing tag. Admittedly I’ve expanded the code but I’m a big believer in more is less (confusing). Of course self-documenting code isn’t new (Steve McConnell etc..) but there does seem to be a real mind set of trimming code down to the smallest, most elegant (i.e. unreadable) fragments. It’s as if we’re developing assembler code to run on the chip of a washing machine. Except most of us aren’t and never will be.