"It's some nice code," smiled the software architect at Petr Valasek's company, "it needed refactoring before it was ever written. But the good news is, you get to refactor it now."

And just like that, Petr was a new father. His baby was the bastard child known as the GIS Hardware Monitoring module. It wasn't pretty, but Petr knew it had potential and was excited to refactor the code. One of the first things he came across was this.

switch ( nState )
{
   case GIS_NEEDLE_STATE_ERROR:
     Diederick;
     break;

   case GIS_NEEDLE_STATE_UNKNOWN:  
     Jan; 
     break;

   case GIS_NEEDLE_STATE_INSERTED:
     Piet;
     break;

  case GIS_NEEDLE_STATE_RETRACTED:
     Kees; 
     break;

}

Who are these four dutchmen, Petr wondered, and what are they doing in my code? Digging a bit further, he found how the dutchmen were #defined:

/*case GIS_NEEDLE_STATE_RETRACTED:*/
#define Kees (m_nlGISRetracted &= ~(1 << nIndex))

/*case GIS_NEEDLE_STATE_UNKNOWN:        */
#define Jan (m_nlGISRetracted |= 1 << nIndex)

/*case GIS_NEEDLE_STATE_INSERTED:       */
#define Piet (m_nlGISRetracted |= 1 << nIndex)

/*case GIS_NEEDLE_STATE_ERROR:  */
#define Diederick (m_nlGISRetracted |= 1 << nIndex)

As for refactoring, Petr considered combining Jan, Piet and Diederick into a single person ("Hans" seemed like a good name), but was a bit concerned that it might create some "multi-personality issue." Of course, not that it mattered because all GIS hardware is considered "retracted" when and only when m_nlGISRetracted equals zero.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!