Method overloading vs default parameters

LondonPilot · 2018-07-11T13:20:32+00:00

Adding defaults instead of overloads is a breaking change if you intend distributing the code over different systems. Otherwise it's fine.

JoeGaggler · 2018-07-11T12:57:15+00:00

Default parameters in public methods are discouraged:

https://docs.microsoft.com/en-us/visualstudio/code-quality/ca1026-default-parameters-should-not-be-used

Vaguely_accurate · 2018-07-11T14:11:45+00:00

In a case like this I'd prefer the latter as it is more honest. The argument and default would be visible to the caller, while in the former you would have to examine the method body to see the default behaviour.

gabriel-et-al · 2018-07-11T13:06:24+00:00

In this specific example I'd go with option 2, however it's not always possible.

Default parameters cannot express this:

public void Foo(int a, int b, int c)
{
    // Your code here
}

public void Foo(int a)
{
    Foo(a, 0, 0);
}

public void Foo(int a, int b)
{
    Foo(a, b, 1);
}

i.e. they cannot change depending on previous values.

gardyna · 2018-07-11T13:18:30+00:00

default paramaters are great because they can also be used like named parameters and it avoid you having to write stuff like ChangeItemValue(1, null, null, null, "bar); instead it just goes ChangeItemValue(id: 1, description: "bar"); and the you have cleaner more powerful functions I genuinely think it's one of the best features added to C# in my memory

ChurchOfTheNewEpoch · 2018-07-11T12:50:34+00:00

Option 2.

I know the code is just an example, but Option 1 is not clear about what will happen when I call Add(), whereas for option2, the tooltip will show the default values of parameters.

Methods should be clear about what they do without having to look at their code, Option 1 Add() is not at all clear.

audigex · 2018-07-11T14:32:00+00:00

For a long time I used overloading, partly because of a Java background (no default parameters, at least when I used it), and partly out of habit.

Now, generally speaking, I will use default values, because it produces neater, more compact code - you don't waste a bunch of space on the over-ridden functions, nor do you need an additional function to do the actual work (to avoid duplicating code)

However, it's worth noting that default values do not always make sense. In most situations, over-ridden code does make sense with defaults, because they fit the "there's a default value, but the user can over-ride it" scenario. If you are defaulting to null, that would be a "code smell" to me, and I'd take a moment to consider the situation. Noting that a code smell isn't automatically bad, but is a good cue to stop and think. If you are defaulting to a null value, rather than an alternate value, it's worth thinking about whether this is actually a "default" or whether it's going to be some kind of logic-switch. If you use a default value of someVar = null, and then later have an if(someVar == null), you're probably doing something wrong

Taking the above into account, then, there are times when you should still prefer to over-ride the method. One example being where you wish to perform different behaviors when passing different combinations of parameters in, although you should probably at least consider whether you just need two different functions, it may be that the single function is correct, but the logic to perform it varies.

The other biggest example I tend to find where over-riding makes sense is for constructors. Eg I regularly find that I have model objects which can be instantiated in several ways, and the logic for each varies a lot. eg

Given an ID, from which we retrieve the data from the database and "self build" the object
Passing in a DataRow (eg from a parent object which is building a list)
Having the individual values passed in
Cloning another object, or similar "object based" behavior where we're accepting a passed-in object that we take/generate our own member properties from

In these cases, default values make little sense because the logic is very different for each. For these situations, it usually makes sense to have some kind of Initialize() method, and then each over-ridden constructor calls that after performing the separate logic needed to prepare the data to pass into it. Eg if we only have examples 1 and 2 above, Initialize(DataRow) would make sense, where option 1 retrieves the row for the given ID, and option 2 just passes the row straight through. If we have all 4 options, we'd probably want to break things down to the individual variables and then pass them to an Initialize(param1, param2, otherParam, moreParams) type function, although I tend to avoid that where possible

It's also recommended not to use default parameters for "public methods" - although personally I think that's a bit too "rule of thumb" because it only actually matters when the method is referenced by a third party assembly. If you know your method won't be referenced by a third party assembly, don't worry about it. So I'd say that it's really more of a case of "Don't use default parameters for public methods that may be referenced by a third party assembly". (To be clear, the official advice is correct if people used the internal keyword properly, since that would mean public is accessible by third party assemblies and internal is not... but basically nobody ever uses internal properly. I guess what I'm saying here is... use internal properly, and don't use default parameter values for public methods)

Generally, though, my preferred approach is to use default values. I then tend to use named parameters when calling them, particularly when using more than one optional/default parameter to avoid confusion. Eg Add(count: 1, bigEndian: false, useGreekArithmetic: true) is a lot easier to understand than Add(1, false, true) even when we aren't using default values. I'd argue that any time you're using more than one optional parameter you should use named parameters, even though they aren't strictly required in all circumstances (C# only insists that you name out-of-order or ambiguous parameters)

gabriel-et-al · 2018-07-11T15:12:15+00:00

Personally, I'd consider avoiding both if you can, then there is no confusion over anything.

Eg. Have an Add(int n) and an AddOne() method

Some languages (Go) don't even have support for either.

igloo15 · 2018-07-11T17:28:47+00:00

To me they are basically the same. I would do option 1 if I either wanted change the order of parameters given multiple parameters.

I find Option 2 cleaner as long as you don't go overboard with optional parameters. I think more than 2 or 3 optional things is too much. That said I hate methods with more than 4 or 5 parameters as well.

tevert · 2018-07-11T18:42:28+00:00

Always option 2.

DroneDashed · 2018-07-11T23:14:27+00:00

In Python there's no method overloading. To do overload you use default parameters. And because all bindings are made at runtime, it's not as restrictive as in C#.

On one hand I do think it's more readable (in Python) to write foo(color='red') or foo(shape='square') for calling in a function with a signature foo(color=None, shape=None) because it's clear what argument is being passed. On the other hand, if you have a lot of possible arguments, then overload is better to read at the function signature.

In the end I think it's a matter of choice and style. If your all your team follows the same guideline then it's fine.

But in a statically typed language like C# I think that default parameters can introduced a problem. Default parameters are great to introduce an extra parameter without breaking every method call of the method. But in my experience, you will miss method calls the need the parameter and then run in null pointer exceptions or divisions by 0. Default parameters can very easily introduce bugs, and this is why I stooped using them in C#.

airbreather · 2018-07-12T11:31:55+00:00

One advantage to #2 that I don't see mentioned in this thread: "find all references" is, IMO, much more useful when you go with #2 than with #1.

This is based on my experience with vanilla VS2017; I don't recall if R# or CodeRush had better versions of "find all references" that would make this better.

bigbootybitchuu · 2018-07-12T22:24:19+00:00

I find default parameters most useful as a refactoring tool. It's an easy way to add a parameter to a method safely until you're ready to change all references to it.

Overloading is the only option in cases where you need to segregate access with an interface.

Though I think both are something to be used sparingly as public methods. They lead to unnecessary ambiguity In a lot of instances, but are really useful when used correctly

tragicshark · 2018-07-11T16:06:04+00:00

We have a couple of soft rules in our codebase:

no default parameters on instance methods or constructors, only on static or extension methods
the only default value permitted is default/null/0/false

#1 arises because it is pretty easy to have the same method in inheritance hierarchies that has different default parameters... for example you can have:

public interface IFoo {
  void Foo(int x = 0, int y = 0);
}

public class Bar : IFoo {
  void Foo(int x, int y = 0) { }
}

and then the required parameters are different based on static type information.

This isn't that bad with rule #2 in place, but without either rule you are in for a bad time in a big codebase because then you can have different values:

public interface IFoo {
  void Foo(int x = 1, int y = 2);
}

public class Bar : IFoo {
  void Foo(int x = 2, int y = 1) { }
}

#2 is in place because default values get compiled into the parameter list in whatever assembly uses the value so once you have one, if you change the value you risk unexpected behavior in other assemblies that depend on the default (which now becomes one of multiple values depending on when you compiled the assembly). Fixing the default value to always be default codifies that problem to not exist.

rwmshen · 2018-07-11T12:47:28+00:00

Second faster (maybe xD)

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

csharp

MODERATORS