When my application starts, it sets in motion a process by which an event is received back at the main form. It's an event that's common enough (let's say, "Maximize Window") but the first time I receive it, I have to process it in a special manner. So, I have code like this:
class MyMainForm{ ... big long complex code ... bool firstTimeThroughEventHandler = true; void MyEventHandler(object o, EventArgs e){ lock(this){ if(firstTimeThroughEventHandler == true) { firstTimeThroughEventHandler = false; ... one time code ... } } } ... lots more code ... }
So this is just begging for refactoring, right? You have one-time behavior, an instance variable used as a flag, a (slight) performance hit that is not needed 99.9% of the time, etc.
But the thing is, I can't shake the feeling that anything I do to refactor it will make the code less clear. Of course I can refactor a new class to hold the event handler, and attach and detach it to the event, and, y'know, yeah, fine. But, geez, adding a class to a project introduces a mental burden, too, one that seems to me at least as great as "oh, that variable's a flag that's used by that event handler. It doesn't mean anything anywhere else."
Also, note that I don't have any other behavior in the event handler. If it were "if firstTimeThrought { code }else{ other code}" the decision to refactor would be easy. But this is trivial cyclomatic complexity: 1 entry point, 1 decision, 1 exit point.
What do you think?