A subroutine with 61 arguments is dreadfully expensive in terms of people time! Just think of the testing. The combination of tests cases you need to even partially cover such a beast is outrageous. And if everyone who needs to use the thing has to spend several days puzzling out the API, that's a huge hit.
Don't look at this as an excuse to pass a hash, look at it as an opportunity to refactor the subroutine.
The only time I've seen something with anywhere near that many parameters was in old (non-OO) FORTRAN code. I'll bet that many of those 61 parameters represent aspects of objects. Discover and create the right objects, and a good percentage of those parameters go away. And you can unit test the objects individually. Verifying that the internal states of several objects are consistent is much easier than flattening out and combining their internal representations, and then verifying that the resulting pile of values is in a consistent state.
Chances are also good that your subroutine is trying to do too much, but without seeing code, that's hard to tell.
In reply to Re: passing subroutine args as a hash: why not?
by dws
in thread passing subroutine args as a hash: why not?
by Willard B. Trophy
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |