A simple way to make your code better: Stop adding more parameters

November 11, 2009 – 9:46 pm Tags:

You need to add some new functionality to your function or class. Let’s say you need to remove all objects stored, but optionally also call a method on them.

It’s pretty simple, isn’t it? Let’s just add a parameter to removeAllObjects! If you make it true, the additional method is called, otherwise not.

Except it’s not really such a good idea at all…

What’s wrong with parameters?

Is there something wrong with parameters?

No, not really.

Parameters are good, but there are some things that you need to consider when creating functions with parameters, or when adding parameters to existing ones. Let’s look at them in a bit, but first let’s do a quick comparison.

Here’s some code:

$pump = new OilPump();
$pump->turnSwitchOff(true);

Compare it to this:

$pump = new OilPump();
$pump->turnSwitchOff();
$pump->deactivate();

Did you know what the parameter for turnSwitchOff did in the first snippet? Unless you’re really good at guessing, you probably had no clue.

This illustrates the case against parameters quite well: In many cases, some parameters are not obvious at all, and to know what the parameter does, you would have to look it up in your docs or source.

Rules for good parameters

The first rule is easy: Less parameters is good. However, this does not mean you should avoid parameters like plague – while less is good, not having enough and instead having more functions is often worse.

The second rule is that your parameters should be related to the function. In our first example and the code sample, the parameters we talked about weren’t related to the functions at all. If the parameter is related, and easily understandable from the function name, it’s probably OK. For example:

$store->findByName('foo');

Pretty self-explanatory, right?

Third rule is be consistent: The order of parameters is important, and if you have a bunch of functions that deal with similar data, try to keep the parameter order the same. For example, if you’re writing asynchronous JavaScript code, always have the callback function be the last parameter – or the first, doesn’t matter as long as it’s consistent across your code.

The fourth rule is use the language you program in to your advantage. In Python, you can use “kwargs” like this: some_function(name='John', age=32). In JavaScript, you can pass an object literal. Remember that while this makes the code easier to read, it may still be difficult to know what parameters you can pass into the function when writing it in the first place.

<Your rule goes here. Write it in the comments!>

Conclusion

Putting in parameters for functions/methods without thinking much is an easy way to end up with a lot of confusing code. It’s a good rule to think if it’s possible to guess the parameter’s meaning from the method’s name or other clues. When in doubt, adding the new functionality with a new method is usually a safe route – but don’t forget that sometimes you can’t have everything.

Sometimes you need to have a bunch of parameters. In situations like these, it’s important that you have good docblocks (PHPDoc, JSDoc, some other flavor) and good parameter naming – while less parameters is often good, it’s easy to go too far.

Share this:
  1. 14 Responses to “A simple way to make your code better: Stop adding more parameters”

  2. Ya, I’m finding myself trying to cut back on the number of parameters I’m using.

    I think most people forget to have the method name explain the parameters.

    -Added to DZone-

    By CodeJustin on Nov 12, 2009

  3. While having as little parameters as possible is sound advise, I don’t think programmers are to blame for having to guess which parameter does what, which type it should be and where its place is in the function call.

    Named parameters solve a great deal making your code more readable, and if the programming language you use has them use them all the time.

    By david on Nov 12, 2009

  4. I’m a huge fan of using an object literal to specify parameters (in JavaScript). Makes it much easier to handle null/default values, and makes the code a tad nicer to read/maintain.

    Great article! I’d love to read more like this…

    By Frank Manno on Nov 12, 2009

  5. There is another alternative to lots of boolean operators: using a bitmask.

    Compare
    $pump = new OilPump();
    $pump->turnSwitchOff(true, false, true, false, false);

    to
    $pump = new OilPump();
    $pump->turnSwitchOff(OilPump::CHECK_LEVELS | OilPump::DEACTIVATE);

    http://php.net/operators.bitwise

    By Arnold Daniels on Nov 12, 2009

  6. While a bitmask could be used as you propose, in this case it wouldn’t really be a good idea in my opinion.

    However, if you had something like setFlags(SOME_FLAG|OTHER_FLAG), or other similar method, it could indeed be a good idea.

    By Jani Hartikainen on Nov 12, 2009

  7. Reminds me of some code I inadvertently messed up the other day… the function that was being called had 8 parameters. None of them documented. My favourite parameters were $where and $other. Completely useless to anyone who doesn’t read the whole function all the way through. ARGH!

    By SeanJA on Nov 13, 2009

  8. Minimizing the number of parameters that a function takes, gives many advantages like:

    1. reduces the external dependency
    2. If its an API function, then the user of that API need not to remember all the parameters
    3. Increases the security of the code, as all the inputs are evil, unless proved otherwise.

    By Veera on Nov 16, 2009

  9. One thing I’ve always liked to do is group optional parameters into an associative array, called (fittingly) $options. Internally, I create another associative array with reasonable defaults for those options. Then a simple array_merge($defaults, $options) gives me a single place for all optional parameters.

    This keeps the function focused on only needing required parameters, without the signature getting totally out of hand. It’s a similar pattern to a lot of javascript widgets.

    By Chris Henry on Dec 12, 2009

  10. While the array pattern is sometimes nice, I think it has some problems.

    Firstly, you cannot easily use a phpdoc or other doc block to tell required parameters. Sure, you could include a text explaining what the array takes, but there is no defined standard.

    Second, it makes it more difficult to see how many parameters the function actually takes.

    Perhaps some others too, but these two are the main ones off the top of my head. I tend to favor actually defining the parameters by name :)

    By Jani Hartikainen on Dec 12, 2009

  1. 5 Trackback(s)

  2. Nov 12, 2009: Bytes in the Margin :: More Parameters != More Better
  3. Nov 12, 2009: Jani Hartikainen’s Blog: A simple way to make your code better: Stop adding more parameters | Webs Developer
  4. Nov 13, 2009: Adrian Dvergsdal (atmoz) 's status on Thursday, 12-Nov-09 23:00:58 UTC - Identi.ca
  5. Nov 19, 2009: Revue de presse | Simple Entrepreneur
  6. Jul 11, 2013: More Parameters != More Better | Bytes in the Margin

Post a Comment

You can use some HTML (a, em, strong, etc.). If you want to post code, use <pre lang="PHP">code here</pre> (you can replace PHP with the language you are posting)