Carolina Cyclone (Double Loop)

It was early in Seth's tenure at PicoServices Inc. when he first heard about Joe.

"Oh, man," he was told by a coworker he'd recognized as having a good head on her shoulders. "I can't wait until you end up at a Joe review."

"Joe? Why's that?" he asked, tilting his head.

"Nope, no way. You get to experience Joe the hard way."

Over the coming week, Seth was pretty sure he'd caught people taking bets for something to do with the coming code review, but he wasn't sure why. Joe had seemed like a reasonable fellow when they'd reviewed Beth's code together, and he'd had a few useful pointers for Seth about how to talk to one of their project managers. What could be so bad?

When he got to the conference room where the team had gathered to review Joe's new code, Beth beckoned him over to sit by her, right at the base of the U-shaped table where he had a prime view of the projector. As Joe got his laptop plugged in, most of the room seemed to be watching Seth's face with varying degrees of subtlety.

Oh ... kay ... Seth thought, bracing himself for some weird hazing ritual.

Then the projector flickered to life, and he settled in to read the function.


public string DoSomething()
{
  string r = null;
  try
  {
    do
    {
      if (!somePrecondition) break;
      if (!someOtherPrecondition) break;
      //Code goes here
    } while(false);
  }
  catch (Exception e)
  {
    r = "Error: " + e.Message;
  }
  return r;
}

Joe walked them through his method, explaining the preconditions, then the business logic. Questions arose about this and that variable naming, inconsistent spacing, et cetera.

Finally, Seth blurted out the obvious question: "Why while false?"

"Obviously, you only want to have a single return. It's much easier to trace that way," Joe replied.

Seth begged to differ. "Okay, and?"

"This way, the rest of the code isn't evaluated if the precondition is true."

Seth blinked. "Why not just use if statements?"

"I did. You see?"

"No, but I mean, put your code in the else."

"Ah, but it gets so messy, all the indentation. Much cleaner this way."

"But ... but that's not ... what? You spent extra time writing lines that do nothing!"

Joe smiled. "Oh, no, of course not. I have a template I use for all my methods."

Chuckles broke out across the room, and a few knowing looks were exchanged.

"He always writes like this," Beth explained in a whisper. "Don't feel bad. We've all tried to talk him out of it."

Seth shook his head. "Okay, whatever, but, why return null?"

"Otherwise, I couldn't return a string here, if there's an exception," Joe explained. "You can't return if it's void."

"Okay but, that's what the exceptions are for, surely. Why not just let it bubble up?"

"And make the calling code clean up the mess? No, no. This is much cleaner."

It was futile. Joe kept insisting that his code was "cleaner," no matter what Seth said.

But Seth would not be deterred. Over the coming weeks, he kept trying to talk to Joe about these anti-patterns, digging up articles about goto, explaining compiler optimization, even roping in experts when they were sent to conventions.

Finally, after 2 months of this, Joe admitted to seeing the light and agreed to change his pattern. The other developers took Seth out to celebrate his success, and he didn't buy a single beer all night. Surely now, things would start looking up, right?

As soon as he saw Joe's next checkin, Seth knew he had to write us:


for ( ; ; )
{
      if (!somePrecondition) break;
      if (!someOtherPrecondition) break;
      //Code goes here
  break; // Always break out of the loop at the end
}
[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!