views:

944

answers:

9

Occasionally I'll write a PHP function with a single input, an associative array containing all of that function's inputs. This has benefits such as not having to remember the correct order of inputs, but I've also noticed it makes implementing changes to large codebases much easier; when I need to add another variable, and that variable has to pass through 4 or 5 pre-existing functions, it's much easier when I can just stick it in the array and pass it along.

My question is, is there a downside to doing this?

I rarely see functions written this way in examples, or in open source I use, which leads me to believe there is probably a downside. If there isn't a reason not to do it then why not write all functions this way?

UPDATE

Thanks for all your answers. It looks like two major problems stand out:

Code readability - impossible to tell what variables are going into a function and what they're for

Variable creep - Could wind up with massive arrays bouncing from one function to the next; one should not pass parameters to functions that don't require them

Which are both great points I did not think about.

It seems the general gist as well is that code where this is an issue, should probably be converted to a class. Unfortunately in this specific project such a refactoring is beyond the scope, but I also think Bill Karwin's solution is good - pass an array of optional variables

+5  A: 

The downside is that anyone looking at your code (other than you) would have no idea what parameters are coming into a method, where they came from, or what they are for. They would also have no idea how to call a method since it isn't clear without looking at the code exactly what is required inside that "parameter array".

Eric Petroelje
+1  A: 

Listing each parameter can increase code readability. Passing a single associative array wouldn't necessarily explain what kind(s) of data are being passed to a function.

Evan Meagher
A: 

If I were to pick up your function and see that it simply starts referencing hash values within a single function argument, I would be a bit confused. Explicitly stating the variables and giving a bit of documentation within a docblock using @param helps tremendously. Having to add an argument in two places is a minor cost compared to the readability listing arguments yields.

Andrew Noyes
+2  A: 

presumably one of the downsides is that you'll end up with way too many parameters. This leads to the problem that the code is likely to lose it's readability.

In a strict Object-Oriented approach you would convert all these parameters that are "passed through" multiple function-calls into instance-variables of the classes holding the methods.

You should never pass parameters to functions that are not actually required by them.

marvesmith
+1 - beat me to it
John Rasch
A: 

The biggest code smell here is that adding another variable would cascade through 4-5 different functions. I can't really think of a reason this would need to happen.

It sounds like you need to refactor this code into a class so that then you can pass the values into a constructor one time, and save them as member variables.

John Rasch
A: 

It makes it a lot easier to generate documentation if you have the parameters named and passed in separately. You might think using an array makes it easier to add new code, but the upside there doesn't beat out readability. Plus go away from your code for 2 months and come back...figuring out in what order to add params to your array in which situations will become a massive headache.

Cameron
+1  A: 

This isn't necessarily that bad of an idea, since PHP lacks the "keyword arguments" feature found in many other modern programming languages (Python, Ruby, etc.). However, there are definitely a few problems with it:

  1. If you change the parameters that a function accepts, then it's likely you'll have to change some code where it's called anyway, to match the new parameters.

  2. If you're using these arrays extensively, and in many function calls taking an array and simply "passing it along," that might be a sign that you should think about turning some of those parameters into a structured class.

  3. If you're using these arrays as a mutable data structure, you don't necessarily know that the array you have after calling the function is the same as the one you passed in. This will probably come back to get you at some point.

Paul Fisher
+1  A: 

why not write all functions this way?

For that matter, why not forget about parameters completely, and use global variables for everything? (kidding)

Passing an associative array has one useful advantage: you can make multiple function parameters optional, and you can pass a value for the Nth parameter without having to pass a value for the N-1st parameter.

But you have no way to make mandatory parameters with a compile-time error if you don't pass them. Neither can you declare type-checking.

You'll have to write code inside the called function to check for the presence and the type of required parameters.

An alternative I have used is to declare conventional parameters for those that are mandatory, and then as the last (optional) argument, declare an associative array called $options that contains only the optional items.

function database_connect($dbname, $user, $password, array $options = array())
Bill Karwin
A: 

In some cases this does make sense I feel, but often you can simplify things by creating multiple methods with slightly different behaviours. The name of the method will then make it clear what it's for.

In general if your functions have > 3 arguments it will become unreadable anyway.

As an alternative, and often used pattern is making the single argument of your function a (classed-)object. The 'parameter class' will define exactly what's supported.

Evert