Long parameter list

Long parameter list


Long parameter list in a method call is a code smell. It indicates that there might be something wrong with the implementation.

There is no single rule for how many is too many parameters. Usually more than three or four is considered too many. Here is explained why and how to refactor such cases.


A long parameter list is easy to spot. Symptoms of too many parameters include:

  • It is hard to use a method call or to get the parameters in correct order.
  • It is hard to read and interpret what a method call does.
  • A method call has boolean parameters.
  • A method call has null parameters as optional parameters.

Consider the following example:

calculateStatistics(customer, unit, null, true, false);

It is not really clear what each parameter does. To find out you are forced to read the documentation.


There is usually a cause for the symptoms described. Maybe you needed more data in a method. Maybe you tried to make a method generic and handle different scenarios. Having a long parameter list can come down to:

  • Trying to do too many things in a method.
  • Trying to minimize dependencies between objects.


Depending on the situation there are different ways to make it better. These simple techniques show how to refactor the code in each case. Keep in mind that the examples are very simple on purpose!

  • If the parameter can be obtained from another object, replace parameter with a method call. The object can be a field in the class or passed as a parameter.
  • If the parameters belong to a single object, preserve whole object.
  • If the parameters come from different objects, introduce a parameter object.
  • If there is a boolean parameter, consider replacing the parameter with explicit methods.

Replace parameter with method call

int price = quantity * itemPrice;
discountLevel = getDiscountLevel();
double finalPrice = discountedPrice(price, discountLevel);
int basePrice = quantity * itemPrice;
double finalPrice = discountedPrice(basePrice);

Preserve whole object

int x = point.getX();
int y = point.getY();
window.setLocation(x, y);

Introduce parameter object

account.balanceBetween(startDate, endDate);
account.balanceBetween(new DateRange(startDate, endDate));

Replace parameter with explicit methods

setValue("visible", true);


These kind of changes are not made just for fun. Benefits of refactoring include:

  • Improving code readability.
  • Possibly reducing duplication that was not noticed before.


This code smell is something that does not guarantee a problem. Sometimes you might decide to go with a long parameter list.

  • Sometimes passing a whole object would cause an unwanted dependency between objects.
  • In some cases the parameters can be unrelated. Grouping them in a parameter object does not make sense.


Long parameter list makes the code harder to use and understand.

Long parameter list can be caused by too complex methods. Another reason is avoiding dependencies.

One way to reduce number of parameters is to replace a parameter with a method call. You can also preserve a whole object or introduce a parameter object. Another way of reducing parameters is replacing a parameter with explicit methods.

Refactoring makes the code easier to read. It may also help to get rid of duplication.

3 thoughts on “Long parameter list

  1. Jere Teittinen

    Good article.

    Question? What would you do if there are let’s say 26 parameters being passed to a method? Just rewrite it in a better, more sane fashion? Or if one really had to, should they go with a parameter object created with let’s say builder pattern? (it’s likely that there are quite a few null parameters in all those 26.)

    • In such case I think the method is trying to do way too many things. I would not try to just replace the arguments with a parameter object. Instead I would try to find the separate objectives the method is trying to accomplish. It is also very likely that some of the parameters actually belong to another object.

      Several null parameters are also a sign that the method is trying to be too generic. The conditional logic such method involves with should be replaced with explicit methods.

      Dividing a long method into several smaller methods and classes is described in my post about Long method.

      • Jeshan

        “Several null parameters are also a sign that the method is trying to be too generic.”
        Love it.
        I think you should highlight this in the post as it’s a very important point.

Leave a Reply