I'm sure you've seen your share of long methods—methods that run several hundred lines.
Some of us may have even written them, probably in those days before we gained our
wisdom to write better quality code.

Long methods are evil on several grounds:

• They're hard to understand
• They're hard to change
• They're hard to reuse
• They're hard to test
• They have low cohesion
• They may have high coupling
• They ten to be overly complex

Often programmers ask, how "long" is a long method? A method is too long if

• you have to scroll down to look at the complete method
• it takes several minutes to understand
• you can't easily write an automated test for it
• you can't state the one prominent purpose for the method

One easy way to address long methods is to use the so called Compose Method Patter.
Your methods then focuses on doing one thing and invokes other methods, all of which
are at the same level of abstraction. The result is shorter, easier to understand methods
in your application.

You say, "OK, I get it, but what about my colleague who has a compulsive disorder to
write very long methods, how do I convince that colleague?"

So you have tried to state the benefits, showed examples, and your colleague still does not get it.
OK, I can suggest one final drastic measure.

On a Monday morning, when you go to work, your colleague asks how your weekend was.
You could say, "It was good, I took the kids to the movie on Saturday and went to the park
on Sunday." That would be like using compose method pattern. You have stated your activities
at one level of abstraction. If your colleague is interested in more details about the movie or the
park, he or she can drill down into the details further asking you how the movie was, and so on.

But, do not reply to that question that way. Instead say, "Over the weekend I got into my car, started it,
drove 5 miles West, took a right turn, then a left turn, then drove another 10 miles, ..." Go at it for
several minutes until your colleague gets frustrated and interrupts you with "What's wrong with you."
Now simply reply, "oh, I though I'll tell you how my weekend way like you write your methods."

@Test
publicvoid convertCtoF()
{
  _converter.from(TemperatureUnit.C);
  _converter.to(TemperatureUnit.F);
  Assert.assertEquals(50.0, _converter.convert(10), 0);
}

@Test
publicvoid convertCtoFFailureForLargeValue()
{
  _converter.from(TemperatureUnit.C);
  _converter.to(TemperatureUnit.F);
  try
  {
    _converter.convert(Double.MAX_VALUE);
    Assert.fail("Expected exception due to overflow");
  }
  catch(ConverterException ex)
  {
    Assert.assertTrue(true); // :) Success
  }
}

@Test(expected=ConverterException.class)
publicvoid convertCtoFFailureForLargeValueLite()
{
   _converter.from(TemperatureUnit.C);
  _converter.to(TemperatureUnit.C);
  _converter.convert(Double.MAX_VALUE);
}

void testConvertCtoFFailureForLargeValueConcise()
{
  _converter.from(TemperatureUnit.C);
  _converter.to(TemperatureUnit.F);
  shouldFail {_converter.convert(Double.MAX_VALUE);}
}

shouldFail ConverterException, {_converter.convert(Double.MAX_VALUE);}