Indecision

or sometimes it's possible to give too many choices.

You've already heard about the C++ app I've inherited. What you don't yet know is how it abuses the registry. A typical export of our registry key in NT4 text format runs to over 500K! Yep, over 500,000 bytes. There are places where it makes perfect sense to have registry settings to control how your app behaves but ye gods - 500 K worth of text to control it? The code is littered with registry fetches; if this value is this then do that, else do that, and if neither case applies do something else. In some cases this makes sense (I can't really discuss the exact details; hence my wishy-washyness) but in most cases the code seems to have been written three or four distinct ways as an exploration of the best way to achieve the end result and the final decision is controlled by the registry. Naturally, now that the hardware has crystallised, the registry setting is always the same. But did the superfluous code disappear? Of course not!

I can understand the exploratory phase of development when the hardware is still in flux; what one finishes this week may not work next week because the hardware has changed. But leaving all that old code in place; compiled into the executable and bypassed at the whim of a registry setting?

Part of our system involves a device driver which copies a 16K block of data from the hardware into process memory. At various offsets within that block we find data corresponding to condition A in the hardware, or condition B and so on. The way we access data corresponding to condition A is we read a value from the registry that tells us the offset from the start of the block to the data of interest and (possibly) a bit mask that defines which bits of the word, dword or whatever are relevant. Uh, the registry settings are a mix of decimal and hexl. Offsets are decimal, masks are hex. When I asked my predecessor why he hadn't defined a struct (possibly containing bitfields) that mapped onto the datablock he didn't even understand the question!

For each of our 48 distinct hardware entities we have 126 sets of offset/mask pairs, stored in the registry as comma separated strings, each of which must be parsed possibly dozens of times per second. Is it any wonder we have a performance issue? And then we have registry settings that are read at initialisation time; if you change those you have to shut down the runtime and restart it. A pattern to this? No sirreee Bob!

Over time I plan to remove the superfluous code. Over time I plan to remove those offset/mask pairs and define a structure that maps onto the data. All I really have to do is find the time to do it and have a life as well .

For the record; having a life wins.