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?