Refactoring methods in existing code base with huge number of parameters

Question

I have inherited an existing code base where the "features" are as follows:

• huge monolithic classes with (literally) 100's of member variables and methods that go one for pages (er. screens)
• public and private methods with a large number of arguments.

I am trying to clean up and refactor the code, to leave it a little better than how I found it. So my questions

• is worth it (or do you) refactor methods with 10 or so arguments so that they are more readable ?
• are there best practices on how long methods should be ? How long do you usually keep them?
• are monolithic classes bad ?

Answer 1

is worth it (or do you) refactor methods with 10 or so arguments so that they are more readable ?

Yes, it is worth it. It is typically more important to refactor methods that are not "reasonable" than ones that already are nice, short, and have a small argument list.

Typically, if you have many arguments, it's because a method does too much - most likely, it should be a class of it's own, not a method.

That being said, in those cases when many parameters are required, it's best to encapsulate the parameters into a single class (ie: SpecificAlgorithmOptions), and pass one instance of that class. This way, you can provide clean defaults, and its very obvious which methods are essential vs. optional (based on what is required to construct the options class).

are there best practices on how long methods should be ? How long do you usually keep them?

A method should be as short as possible. It should have one purpose, and be used for one task, whenver possible. If it's possible to split it into separate methods, where each as a real, qualitative "task", then do so when refactoring.

are monolithic classes bad ?

Yes.