Avoid too many arguments in functions


Link to this posting

Postby Ursego » 08 Aug 2019, 08:03

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

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


Benefits:

• More compact and readable code. 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 whether or not they belong to one set. Many times, that is 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 used and 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, you don't need to create many overloads to cover different combinations.

Challenge:

• 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!).

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.

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" - see Keep functions simple). In this case, refactoring to a few functions will naturally decrease the number of the arguments per function.
User avatar
Ursego
Site Admin
 
Posts: 131
Joined: 19 Feb 2013, 20:33



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




cron
free counters

eXTReMe Tracker