Question

I face a situation where we have many very long methods, 1000 lines or more.

To give you some more detail, we have a list of incoming high level commands, and each generates results in a longer (sometime huge) list of lower level commands. There’s a factory creating an instance of a class for each incoming command. Each class has a process method, where all the lower level commands are generated added in sequence. As I said, these sequences of commands and their parameters cause quite often the process methods to reach thousands of lines.

There are a lot of repetitions. Many command patterns are shared between different commands, but the code is repeated over and over. That leads me to think refactoring would be a very good idea.

On the contrary, the specs we have come exactly in the same form as the current code. Very long list of commands for each incoming one. When I’ve tried some refactoring, I’ve started to feel uncomfortable with the specs. I miss the obvious analogy between the specs and code, and lose time digging into newly created common classes.

Then here the question: in general, do you think such very long methods would always need refactoring, or in a similar case it would be acceptable?
(unfortunately refactoring the specs is not an option)

---

edit:
I have removed every reference to “generate” cause it was actually confusing. It’s not auto generated code.

class InCmd001 {

  OutMsg process ( InMsg& inMsg ) {

     OutMsg outMsg = OutMsg::Create();

     OutCmd001 outCmd001 = OutCmd001::Create();
     outCmd001.SetA( param.getA() );
     outCmd001.SetB( inMsg.getB() );

     outMsg.addCmd( outCmd001 );

     OutCmd016 outCmd016 = OutCmd016::Create();
     outCmd016.SetF( param.getF() );

     outMsg.addCmd( outCmd016 );

     OutCmd007 outCmd007 = OutCmd007::Create();
     outCmd007.SetR( inMsg.getR() );

     outMsg.addCmd( outCmd007 );

     // ......

     return outMsg;
  }
}

here the example of one incoming command class (manually written in pseudo c++)

Answer 1

I understand exactly where you’re coming from, and can see exactly why you’ve structured your code the way it is, but it needs to change.

The uncertainty you feel when you attempt to refactor can be ameliorated by writing unit tests. If you’ve tests specific to each spec, then the code for each spec can be refactored until you’re blue in the face, and you can have confidence in it.

A second option, is it possible to automatically generate your code from a data structure?
If you’ve a core suite of classes that do the donkey work and edge cases, you can auto-generate the repetitive 1000 line methods as often as you wish.

However, there are exceptions to every rule.
If the methods are a literal interpretation of the spec (very little additional logic), and the specs change infrequently, and the “common” portions (i.e. bits that happen to be the same right now) of the specs change at different times, and you’re not going to be asked to get a 10x performance gain out of the code anytime soon, then (and only then) . . . you may be better off with what you have.

. . . but on the whole, refactor.