Are optional parameters helpful or a hindrance to application maintenance? [closed]

Question

As stated in the title, are optional parameters, such as those used in C# helpful or are they a hindrance to application maintenance and should be avoided as they can make the code harder to understand?

Answer 1

Optional parameters have, in my experience, been a good thing. I have never found them confusing (at least no more confusing than the actual function), since I can always get the default values and know what's being called.

One use for them is when I have to add another parameter to a function that's already in general use, or at least in the public interface. Without them, I'd have to redo the original function to call one that's got another argument, and that can get really old if I wind up adding arguments more than once.

Answer 2

In general, if you need many/optional parameters often, your functions are doing too much, and should be broken up. You're likely breaking SRP (Single Responsibility Principle).

Look for parameters that can be grouped, eg (x and y, become a point).

Are these optional parameters flags with a default? If you're using flags, the function should be split up.

That's not to say you should never have optional parameters, but in general, more than one or two parameters suggest a code smell.

It could also be a clue that the function, should actually be a class, with the optional parameters changed to properties, and the required parameters part of the constructor.

Answer 3

Optional parameters are just fine

Typically the justification is either that a) you know you have a lot of possible arguments for your method but you don't want to overload for fear of clutering your API, or b) when you don't know all the possible arguments but you don't want to force your user to provide an array. In each case optional parameters come to the rescue in a neat and elegant way.

Here are some examples:

1. You want to avoid overloading and don't want to specify an array

Take a look at printf() from C, Perl, Java etc. It's a great example of the power of optional parameters.

For example:

printf("I want %d %s %s",1,"chocolate","biccies");

printf("I want %d banana",1);

No overloading, no arrays, simple and intuitive (once you've grasped the standard string format codes). Some IDEs will even tell you if your format string does not match your optional parameters.

2. You want to allow the use of defaults and keep them hidden from the user of the method

sendEmail("[email protected]");

The sendEmail method detects that various essential values are missing and fills them in using defined defaults (subject, body, cc, bcc etc). The API is kept clean, yet flexible.

A note on too many parameters

However, as others have stated, having too many mandatory parameters to a method indicates that you probably have something wrong with your design. This is particularly true if they share the same type since they can be switched by the developer by accident leading to strange results at runtime:

String myMethod(String x, String y, String z, String a, int b, String c, int d) {}

is an ideal candidate for the Introduce Parameter Object refactoring to create

String myMethod(ParameterObject po) {}

class ParameterObject {
  // Left as public for clarity
  public String x;
  public String y;
  ... etc

}

This in turn can lead to a better design based on a Factory pattern with a provided specification as the parameter object.

Answer 4

One of the problems with default parameters in C# ( I'm thinking void DoSomething(int x = 1) ) is they are constants. That means if you change the default you will have to recompile any consumers of that method call. While this is easy enough to do there are occasions where this is dangerous.

Answer 5

The problem with optional arguments is that people tend to just tuck on more and more (and more) arguments to the function instead of extracting relevant code into a new function. This is taken to the extreme in php. For instance:

bool array_multisort ( array &$arr [, mixed $arg = SORT_ASC
                      [, mixed $arg = SORT_REGULAR [, mixed $... ]]] )

Answer 6

I have initially loved this feature in python, and used it to 'extend' already used methods. And it looked nice and easy, but it bit back soon; because when I added an optional parameter, this was modifying the behavior of an existing method which the old client relied upon and in a way which was not caught by existing unit test cases. Basically doing this is breaking the Open Closed Principle; code is open for extension but closed for modification. So I believe using this feature to modify existing code is not a good idea; but okay if used from the start

Answer 7

I'd think it would be better to overload a function with different signatures (i.e. parameters) than use optional parameters.

Answer 8

It depends on what your code is doing. If there are sensible defaults then you should use optional parameters but if there are no sensible defaults then adding optional parameters will make your code more complicated. In many instances optional parameters are a neat way of sidestepping nil checks and cutting out branching logic. Javascript doesn't have optional parameters but there is a way to emulate them with || (logical or) and I use it all the time when doing database related stuff because if the user doesn't provide some value then I substitute my own values with the help of || which saves me the trouble of writing a whole bunch of if then statements.

Answer 9

Optional parameters are basically a different way of overloading a function. So this basically comes down to: "is overloading a function bad"?

Answer 10

Optional parameters are a great way to make simple things simple and complicated things possible simultaneously. If there's a clear reasonable default that most users will want, at least in quick and dirty use cases, then they should not have to write boilerplate to manually specify it every single time they call your function. On the other hand, if people might have a good reason for wanting to change it, then it needs to be exposed.

Using a class is IMHO a terrible solution, as it's verbose, inefficient and inconsistent with the typical mental model of what a class does. A function is the perfect abstraction for a verb, i.e. doing something and returning. A class is the right abstraction for a noun, i.e. something that has state and can be manipulated in several ways. If the former should be the API user's mental model, then don't make it a class.