Question

How would you fix the following bad code that passes too many parameters around?

void helper1(int p1, int p3, int p5, int p7, int p9, int p10) {
  // ...
}

void helper2(int p1, int p2, int p3, int p5, int p6, int p7, int p9, int p10) {
  // ...
}

void foo(int p1, int p2, int p3, int p4, int p5, int p6, int p7, int p8, 
         int p9, int p10) {
  helper1(p1, p3, p5, p7, p9, p10);
  helper2(p1, p2, p3, p5, p6, p7, p9, p10);
}

I see two different approaches:

Approach 1: Put all functions in a class

class Foo {
  private:
    int p1, p2, p3, p4, p5, p6, p7, p8, p9, p10;
    void helper1() {}
    void helper2() {}
  public:
    void foo() {
      helper1();
      helper2();
    }
    // add constructor
};

Approach 2: Just pass parameters as a class

struct FooOptions {
    int p1, p2, p3, p4, p5, p6, p7, p8, p9, p10;
};

void helper1(const FooOptions& opt) {
  // ...
}

void helper2(const FooOptions& opt) {
  // ...
}

void foo(const FooOptions& opt) {
  helper1(opt);
  helper2(opt);
}

What are the advantages and disadvantages of the approaches?

An advantage of Approach 1 is that — if you make the helper functions virtual — you can subclass and overload them, adding flexibility. But then, in my case (outside of the toy mini example that I gave) such helpers are often templated, so they cannot be virtual anyway.

An advantage of Approach 2 is that the helper functions can easily be called from other functions, too.

(This question is related, but does not discuss these two alternatives.)

Answer 1

Short Answer:

Happy New Year! I’d avoid option #1 and only go with option #2 if the parameters can be separated into clear and logical groups that make sense away from your function.

Long Answer

I have seen many examples of functions as you described from coworkers. I’ll agree with you on the fact that it’s a bad code smell. However, grouping parameters into a class just so you don’t have to pass parameters and deciding rather arbitrarily to group them based on those helper functions can lead to more bad smells. You have to ask yourself if you’re improving readability and understanding for other that come after you.

calcTime(int p1, int p2, int p3, int p4, int p5, int p6) {
    dist = calcDistance( p1, p2, p3 );
    speed = calcSpeed( p4, p5, p6 );
    return speed == 0 : 0 ? dist/speed; }

There you can group things to be more understandable because there is a clear distinction amongst parameters. Then I would suggest approach #2.

On the other hand, code in which I’ve been handed often looks like:

calcTime(int p1, int p2, int p3, int p4, int p5, int p6) {
    height = height( p1, p2, p3, p6 );
    type = getType( p1, p4, p5, p6 );
    if( type == 4 ) {
        return 2.345; //some magic number
    }
    value = calcValue( p2, p3, type ); //what a nice variable name...
    a = resetA( p3, height, value );
    return a * value; }

which leaves you with a feeling that these parameters aren’t exactly friendly to breaking up into something meaningful class-wise. Instead you’d be better off served flipping things around such as

calcTime(Type type, int height, int value, int p2, int p3)

and then calling it

calcTime(
    getType( p1, p4, p5, p6 ),
    height( p1, p2, p3, p6 ),
    p3,
    p4 );

which may send shivers up your spine as that little voice inside your head screams “DRY, DRY, DRY!” Which one is more readable and thus maintainable?

Option #1 is a no-go in my head as there is a very good possibility someone will forget to set one of the parameters. This could very easily lead to a hard to detect bug that passes simple unit tests. YMMV.