I said:

> PS. I am still trying to live with one of my (fairly recent)
> decisions to use a really long enumeration (also for decoding
> but of a different nature). It does work, but when I go to try
> and debug or extend it then I quickly get lost somewhere after
> line 100 in the function (constantly looking back to see where
> this or that came from). I only wish that I had considered
> some early isolation when I wrote that one. One day I do
> intend to go back and refactor it.

Its worth noting another problem I've had with this code...

I have ended up with half-a-dozen functions all implementing
the same huge enumeration switch. Each is an _almost_ full
duplication of the others.

In the primary/original function I do actual decoding. In the
other cases I am merely looking for some particular piece of
information from or about the encoded string. Some just want
to skip over the variable length areas, some want to pull out
just one chunk of information and so on.

Because there was no early isolation each function was forced
to try and deal with all enumeration facets itself.

This was obviously a bad design decision on my part, but I
did not realise when I started that I would want to do more
than just decode an encoded string. Now I know better, but
now I also have a fairly big job to try and undo the damage.

The point of this little admission of fallibility is just a
reminder to think about how you may be using the encoded
information in the future. Will it only EVER be decoded, or
may you decide pass it around more generically? The answer
to this question may change the way you decide to implement.

--
Geoff Worboys
Telesis Computing