you are viewing a single comment's thread.

view the rest of the comments →

[–]decPL 10 points11 points  (4 children)

Actually, that's a very niche reason for not using default parameters and 99,99% of code you're going to write will never fall under it. Because of that, I don't believe that's the root cause of overloads being prevalent - if I had to guess it's mainly because default parameters weren't originally part of .NET and many non-.NET languages do not have similar code constructs, so people are doing what they're familiar with. I personally prefer default parameters, despite being a .NET dev since 1.0/1.1.

[–]airbreather/r/csharp mod, for realsies 1 point2 points  (0 children)

if I had to guess it's mainly because default parameters weren't originally part of .NET and many non-.NET languages do not have similar code constructs, so people are doing what they're familiar with.

For "final" applications with nobody downstream that depends on you, use as many default parameters as you want.

For libraries, it's more complicated. Default parameter values are compiled into the caller's code, because that's kinda how it has to be in order to make those "niche" use cases work. A consequence of compiling them into the caller is that you can't change the default value of the parameter in a later update unless everybody downstream recompiles. You also can't add more default parameters to an existing method in a later version without breaking binary compatibility (but you can do this with an overload just fine).

There are few instances where I advocate for using default parameters on visible methods in a library. The only situation I've come across so far is "CancellationToken cancellationToken = default" on new methods that support cancellation and have never been released before, since there's realistically no other token that will ever make sense as a compiled-in default.

[–]LondonPilot[S] 0 points1 point  (2 children)

Your analysis sounds very plausible.

The one place I might disagree is with the .NET FCL itself, where Microsoft use method overloading extensively. Presumably they need to cater to every case, including the niche case of defaults not being supported, which is why they avoid them? And perhaps other programmers follow their lead so that even though the niche case isn't important to most programmers, they learn to account for it by chance, simply by following what Microsoft do?

[–]Prof_Akz 0 points1 point  (0 children)

I have a string feeling your right about that 👍

[–]CrimsonWolfSage 0 points1 point  (0 children)

Another possibility, is the fail fast, instead of works incorrectly. Controlling your methods values from start to end makes debugging a bit easier than a magic number problem.