Let's look at the principle again.
Don't keep track of information you don't need.
I remember being asked to look at a customer's program,
and one thing that struck me was that the program had
a bazillion different flag variables that it spent a lot of time
setting and clearing. Here's an oversimplified example:

A naïve reading of the code would lead one to believe that
the main purpose of the program was to set and clear flags!
Upon closer inspection, I found that most of the flag
variables were write-only.
Although the code went to great pains to update the flags
as it ran,
there was no code that actually cared whether the flag was set or not.

I asked the customer liaison about this, thinking that maybe
I missed something.
Maybe the variables were being used in a subtle way that I failed
to appreciate.
Maybe they were used during debugging.

The customer liaison got back to me.
"When I asked them about it, they just said, 'Ah, yes.'
Apparently that code was written by one of their guys named Bob.
I guess he likes to set and clear flags a lot."

But is there any code that actually checks the values of those flags?

"Probably not.
He just set and cleared those flags because he figured maybe someday
he might need them."

Indeed, once in a while, he actually tested one of the dozens of flags
he spent most of his time setting and resetting.
But the vast majority of the flags were write-only.
(And since most of the flags went unused,
I suspect that many of them weren't even accurate.)

Obviously, this is an extreme case of write-only variables,
but it illustrates the point.
Next time, we'll look at one of the consequences of the principle
of not keeping track of information you don't need.

Isn’t it obvious? This is about job security. You throw a few hundred random lines of code in that do nothing and anyone else who takes a look at it will be confused. Also, this is why you should always throw a few for loops in that do some irrelevant calculation a couple million times. You can remove them later and call it a performance improvement.

At least this was only bools – I knew one "Bob" who loved to store information as delimited strings. He was familiar with the concept of arrays, as shown when he used arrays of delimited strings, but the light bulb never lit up.

Job security like that only works if you can convince management that a new guy can’t come in, delete everything, and have a fresh version done in a week. My Bob managed it.

I know it isn’t the same thing, but I once ran into a class that had seven flags and only one of them could be set to true at a given time. In other words, a enum would have worked just fine.

Sure, there isn’t anything technically wrong with it, but when looking at the state machine, if you didn’t know that the flags were mutually exclusive, then the state machine had 128 possible states instead of just seven.

Hmmm… I really do wonder that if Bob is sitting there writing reams of unused code and letting it get into production should he really be coding? Or should his check-ins be automatically redirected to the TheDailyWTF? That is if he is *even* using source control I somehow doubt it.

I’ve never gotten "write terrible code" as job security, to be honest. A good employer will find or invent another project for you to work on because they want to keep you around, and a bad employer will let you go, giving you motivation to go find a good employer.

It’s very common to see code written with the intention that it might be useful some day. In my experience it’s just too hard to predict the future. But then, I get labelled short-sighted for not writing everything as a library. :)

I actually see this as something different: it’s a pattern that’s occasionally useful as a hack, and which Bob has put into his muscle memory for dialog boxes.

For example, some time in his past, he had to deal with Dialogs "A" and "B" that both called setup_widget(). Then a requirement came in that setup_widget() do different things based on the caller. The correct thing to do is refactor, because setup_widget() now has to be two different functions. The hack is to set the calling/is_called flags.

Similarly, I can imagine a "file save" dialog function that should only be called if the underlying data has been changed. Clearly you need some sort of flag — and Bobs system will always provide that kind of flag.

Not to say it’s good code, mind; but it is understandable. It’s not job security, it’s just unfortunate training.

I like to leave space for code that might be written one day as much as the next guy does. But that’s not the same as writing the code in advance.

With write-only flags, there’s an absolute certainty (for certain values of ‘absolute’) that at least one of them will not be updated correctly, and because its never used, you won’t know about that bug. So one day when you write a small bit of code that needs to rely on the flag, you’ll have to search the entire codebase for places it should be set, anyway.

So, you should probably replace all reads of m_fShowingDialog with dialog.IsVisible() – or whatever suits the dialog API in use – and thus not be caching data that you don’t need. ;)

Also, in the sequence "m_fShowingDialog = true; DoModal(hwnd); m_fShowingDialog = false;" I didn’t see any locking, so one day in the future you know that someone’s going to add a thread that assumes m_fShowingDialog is accurate and complain that its not always working right. Of course, even then there will be problems with the typical single-threaded GUI library, but that issue isn’t fixed by an inaccurate flag. (And there’s plenty of cases where the flag introduces a race condition even if your resource happens to be thread safe, so caching without knowing what you’re doing is still wrong.)

Maybe it’s written by staffs of one of the companies that sets target amount of LOC for employees.

Setting/clearing flags is a good way to get away a casual code review when counting LOC(consider even experts like Raymond have to ask before confirming they’re not needed, their uselessness is not readily detectable by whoever sitting above them). This is a useful way to make sure everyone in team meet the target.