Sorry. Geek alert.

We found this…

void log(string message)
{
   try
   {
      blah blah blah
   }
   catch (Exception ex)
   {
      this.log("An exception occurred in logging : {0}" + ex.Message);
   }
}

Warning… geek content… move along now…

public enum LoadErrors
{
   NoError,
   UnknownError
}

Argh! Marks out of ten?

Warning… geek stuff ahead…

Argh. Talk about obfuscation…

// Fire last known state
void fireLastKnownState()
{
   this.State = null;
}

This really doesn’t seem to do what it says on the tin. Until you look at the definition of state…

public State
{
   set
   {
      this.state = value;

      if (value != null)
         fireEvent(value)
      else
         fireEvent(this.lastState)
   }
}

It’s nice to get this sort of reaction to something you’ve created… this was the encore

You can download the code here, but bear in mind you’ll need an Atari 1040ST to run it on.

Ever wondered what people mean when they text you to say “fancy going out for a riot”, or “shall we meet at the cup rump?”.

Well now you can find out!

What is wrong with the following code? (Bear in mind that ‘create_media’ is a highly complex remote asynchronous task involving ejecting and cueing an audio/video port, creating space, starting video and audio codecs and sending network and serial messages between various devices as each status is reached.)

if (can_create_media(x))
{
   bool success;
   success = create_media(x);
   if (success)
      print "media created";
   else
      print "error: media creation failed";
}
else
{
   print "error: can't create media";
}

It looks quite reasonable doesn’t it. That’s until you check the contents of the can_create_media() function. It reads…

bool can_create_media(x)
{
   return create_media(x);
}

So that’s why there are multiple replies and race conditions and intermittent failure.

My Star Wars game that I wrote last year for the ZX Spectrum almost won the comp.sys.sinclair Crap Games Competition. It was jointly awarded 9/10 by the judges, but was narrowly beaten by the George Best Deathbed Simulator.

You can see the annoucement here and all the entries with comments and scores here.

I still love this little bit of C code… I had to spend a few minutes reproducing it for myself just now…

int a;

int x()
{
   int b[1];
   b[2]=a;

   printf("Hello\n");
}

int main()
{
   int c[1];

   a=c[2];
   c[2]=(int)x;

   return 0;
}

Ten points if you can say what happens. A gold star if you can say why.

Oh… and I’m most upset I didn’t realise I should have stayed up last night to see the time/date 01:02:03 04/05/06. It was only pointed out to me this morning. Harumph.

I’m currently visiting a huge amount of error logging code, pulling it from a complicated pile of spaghetti no-one understands into a lean easily useable piece of design. Error logging is absolutely vital in code, and if you’re in any kind of service industry where your only window to problems on site is the returned logs, you need to be careful.

Here are a few musings…

1. Make it easy to use on site. The front-line guys being shot down by the customer while their system blows up do not have a lovely cushy job like you sitting at your desk. Make it easy for them to find logs, and to find relevant parts of logs.

2. Split logs into verbose and normal categories. Don’t overdo the number of categories, but there should be a category which logs everything going on (verbose) and one which logs only error conditions (normal). That way, you can work from the ‘normal’ logs first, and have the verbose ones turned on and returned if necessary later.

3. Don’t log multiple times in a single logic thread. Once a decision has been made by an if, while or case, you don’t need to narrate what is occuring. A log to say which decision has been made is sufficient.

4. Don’t write too many lines of logging where fewer would suffice.

I intend to update this blog with more information, some editing and more case studies. Any input would be appreciated!

Case study 1.

Here, we see a couple of problems:

log("Doing job X")
if (x_handler != null)
{
   log("Calling handler")
   x_handler();
}

Firstly, in a working case, we get two lines of logging. In a non-working case, we only get one. This is the wrong way round - exceptional circumstances should log more than normal circumstances. Secondly, we are always logging this information. If this is a commonly occurring event, you will fill the logs with rubbish and make it difficult to spot errors.

Solution:

if (x_handler != null)
{
   logverbose("Doing job X. Calling handler")
   x_handler();
}
else
{
   log("Doing job X. ERROR: handler was null.");
}

Now, we only ever get one line of logging if job X is attempted - whether it passes or fails. Also, the normal case only appears if we turn on verbose logging. The error case always shows up in the log, and it’s easy to spot and search for.

More great C# code in the project I’ve inherited…

[ChangeControl("Calls the base correctly")]
protected override void X()
{
   base.X();
}

I have checked and according to everyone I’ve spoken to there is absolutely no point to this code. If the base class insited on being overridden, then it would be abstract and therefore there would be no definition for the base.X() method.

Ho hum.