Avoid too many arguments in functions

Link to this posting

Postby Ursego » 08 Aug 2019, 08:03

Group the parameters into common data grouping.

Instead of many input arguments, pass an object or a structure. Instead of many output arguments, return an object or a structure.


• More compact and readable code - a long list of parameters is hard to read, and makes calling and testing the function complicated. If many arguments belong to one entity (like "line1", "line2", "city", "state", "zip" belong to the entity "address"), then, instead of a hodgepodge of arguments, you see a single object with a comprehensible name which immediately conveys the idea what is passed, so you don't need to investigate the arguments to figure out if they belong to one "set", to many "sets" or are independent of each other. That can be much less obvious than in the case of address. Especially when more than one entity are passed.

• As a result, the function is more likely to be reused by different developers, because it is defined in a way that makes it easy to understand and apply in code.

• No code duplication. When the function is called from many spots, identical groups of arguments scattered here and there create their own kind of code duplication: while identical code isn't being called, identical groups of arguments are constantly encountered. Until now, we discussed arguments of one function. But identical groups of parameters are often passed to multiple methods. This causes code duplication of both the parameters themselves and of related operations. By consolidating parameters in a single class, you can also move the methods for handling this data there as well, freeing the other methods from this code.

• If some arguments are optional, then you don't need to create many overloads to cover different combinations (now we are talking about programming languages which don't allow to define parameters with default values).


• If you add a new mandatory field to the passed object or structure, all the calls to the function, where you forgot to pass that field, will be still compiled successfully. So, your function must validate that field and throw an exception if it's empty (see Defensive programming. Defuse time bombs!).

Too many arguments can be a "red light"!

One of the problems that could emerge in our application if we have too many arguments is that the function is doing too many things, not respecting the Single Responsibility Principle ("one method must perform one identifiable task" - read Keep functions simple). A long list of parameters may indicate that the purpose of the function is ill-conceived and that the code should be refactored so responsibility is assigned in a more clean-cut way. In this case, refactoring to a few functions will naturally decrease the number of the arguments per function.

But... how many maximum?

The Clean Code book explains that an ideal argument's number for a function is zero (niladic function). Followed by one (monadic function) and closely by two arguments (dyadic function). Functions with three arguments (triadic function) should be avoided if possible. More than three arguments (polyadic function) are only for very specific cases and then shouldn't be used anyway.

But it's just a guideline, not strict rule that we have to follow no matter what. If the function has less than four arguments, nice. But if I create a private function, called only once, with 10 arguments not related to each other, I will not feel guilty.
User avatar
Site Admin
Posts: 140
Joined: 19 Feb 2013, 20:33

IF you want to ((lose weight) OR (have unbelievable (brain function AND mental clarity))) THEN click:

Traffic Counter

free counters

eXTReMe Tracker