C# Optional Parameters?
-
I just read this[^] and thought "what on earth is going on here"? When I moved from VB.Net to C#.net, one of the big evangelistic arguments was around optional parameters as opposed to overloaded methods. I always liked optional parameters, but was prepared to give them up if the general feeling was that they where evil. Seems they aren't evil any more. I think Microsoft is just messing with my head and they will be removed in 5.0. I do like the named parameters though. I have been wanting those ever since I did some Office Automation stuff.
The trouble with optional parameters comes when you extend them
public static void DisplayName (string lastName, string firstName,
string middleName = null)If I now add a salutation:
public static void DisplayName (string lastName, string firstName,
string middleName = null, string salutation = null)all my code still compiles. And that can be a problem. I have a lot of work to do to identify all the places that I need to pass in the new, fourth, parameter (I must need it in at least one place, or else why change the function). Without optional parameters, the compiler does my impact analysis for me. In this case, the worst that happens is that the salutation is missed off a displayed name, but in some cases, you can introduce some subtle bugs.
-
I just read this[^] and thought "what on earth is going on here"? When I moved from VB.Net to C#.net, one of the big evangelistic arguments was around optional parameters as opposed to overloaded methods. I always liked optional parameters, but was prepared to give them up if the general feeling was that they where evil. Seems they aren't evil any more. I think Microsoft is just messing with my head and they will be removed in 5.0. I do like the named parameters though. I have been wanting those ever since I did some Office Automation stuff.
-
The trouble with optional parameters comes when you extend them
public static void DisplayName (string lastName, string firstName,
string middleName = null)If I now add a salutation:
public static void DisplayName (string lastName, string firstName,
string middleName = null, string salutation = null)all my code still compiles. And that can be a problem. I have a lot of work to do to identify all the places that I need to pass in the new, fourth, parameter (I must need it in at least one place, or else why change the function). Without optional parameters, the compiler does my impact analysis for me. In this case, the worst that happens is that the salutation is missed off a displayed name, but in some cases, you can introduce some subtle bugs.
-
The trouble with optional parameters comes when you extend them
public static void DisplayName (string lastName, string firstName,
string middleName = null)If I now add a salutation:
public static void DisplayName (string lastName, string firstName,
string middleName = null, string salutation = null)all my code still compiles. And that can be a problem. I have a lot of work to do to identify all the places that I need to pass in the new, fourth, parameter (I must need it in at least one place, or else why change the function). Without optional parameters, the compiler does my impact analysis for me. In this case, the worst that happens is that the salutation is missed off a displayed name, but in some cases, you can introduce some subtle bugs.
-
But now you can have named parameters and optional parameters and have just one method. You can extend it as much as you like and still know that all instances reference the same method. Seems easier to me. (I am prepared to be wrong :) )
Named parameters have the same problem. How do you guarantee that you have passed in the fourth parameter everywhere you should have?
-
The trouble with optional parameters comes when you extend them
public static void DisplayName (string lastName, string firstName,
string middleName = null)If I now add a salutation:
public static void DisplayName (string lastName, string firstName,
string middleName = null, string salutation = null)all my code still compiles. And that can be a problem. I have a lot of work to do to identify all the places that I need to pass in the new, fourth, parameter (I must need it in at least one place, or else why change the function). Without optional parameters, the compiler does my impact analysis for me. In this case, the worst that happens is that the salutation is missed off a displayed name, but in some cases, you can introduce some subtle bugs.
about 20 overloads for MessageBox.Show[^] The cases where it subtly fails are much less than where it helps. A less subtle bug would be changing
public static void DisplayName (string firstName, string lastName = null)topublic static void DisplayName (string firstName, string middleName = null, string lastName = null)ouch! But hey, we can make it, we can break it.Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server. -
The trouble with optional parameters comes when you extend them
public static void DisplayName (string lastName, string firstName,
string middleName = null)If I now add a salutation:
public static void DisplayName (string lastName, string firstName,
string middleName = null, string salutation = null)all my code still compiles. And that can be a problem. I have a lot of work to do to identify all the places that I need to pass in the new, fourth, parameter (I must need it in at least one place, or else why change the function). Without optional parameters, the compiler does my impact analysis for me. In this case, the worst that happens is that the salutation is missed off a displayed name, but in some cases, you can introduce some subtle bugs.
Electron Shepherd wrote:
all my code still compiles. And that can be a problem. I have a lot of work to do to identify all the places that I need to pass in the new, fourth, parameter
Actually, the fact that your code sill compiles is a good thing. Instead of hunting the DisplayName calls thought the code, all you need to do is make sure DisplayName handles salutation == null properly. Which it should, optional parameter or not. Even if you do want to check all the DisplayName calls, you can find all references with just two clicks. Doesn't seem like a lot of work to me.
We are using Linux daily to UP our productivity - so UP yours!
-
Named parameters have the same problem. How do you guarantee that you have passed in the fourth parameter everywhere you should have?
Electron Shepherd wrote:
How do you guarantee that you have passed in the fourth parameter everywhere you should have?
Um, by knowing your code base, checking and testing? Same as when you refactor your code and make alterations to what an overloaded method does. I realise that they are not ideal for all situations and that some people have coding styles that don't gel with the idea.
-
Electron Shepherd wrote:
all my code still compiles. And that can be a problem. I have a lot of work to do to identify all the places that I need to pass in the new, fourth, parameter
Actually, the fact that your code sill compiles is a good thing. Instead of hunting the DisplayName calls thought the code, all you need to do is make sure DisplayName handles salutation == null properly. Which it should, optional parameter or not. Even if you do want to check all the DisplayName calls, you can find all references with just two clicks. Doesn't seem like a lot of work to me.
We are using Linux daily to UP our productivity - so UP yours!
rastaVnuce wrote:
you can find all references with just two clicks.
I'm guessing you don't share code between different projects, then?
-
Electron Shepherd wrote:
How do you guarantee that you have passed in the fourth parameter everywhere you should have?
Um, by knowing your code base, checking and testing? Same as when you refactor your code and make alterations to what an overloaded method does. I realise that they are not ideal for all situations and that some people have coding styles that don't gel with the idea.
On large systems, one person won't know the whole code base. The function may be used by others, in ways that you don't know (and therefore won't test).
-
Named parameters have the same problem. How do you guarantee that you have passed in the fourth parameter everywhere you should have?
If the fourth parameter has this relevance why do you set some default value? Wouldn't it be better to set it as 3rd parameter with no default value and let to compiler spit out like hell? By the way you would run in the same problem if there where no default value: Your example above without default values:
void func(string szParam1, string szParam2) { ... }
void func(string szParam1, string szParam2, string szParam3) { ... }Now if you add some parameter with a default value it should look like this:
void func(string szParam1, string szParam2) { ... }
void func(string szParam1, string szParam2, string szParam3) { ... }
void func(string szParam1, string szParam2, string szParam3, string szParam4) { ... }This is exactly the same problem. If you solve your problem by adding an important parameter with default value and asking yourself if you got all places where you need this parameter, then you have no problem with your source code. The problem lies in your application design. I really like it to get default values back. :-D And I never ran in the evil-default-value-problem in my whole lifetime!
Greetings Covean
-
rastaVnuce wrote:
you can find all references with just two clicks.
I'm guessing you don't share code between different projects, then?
That's a point, but still... You can force the compiler find the location by just making them non-default. (Yo do have a batch build over all projects involved, don't you?)
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server. -
On large systems, one person won't know the whole code base. The function may be used by others, in ways that you don't know (and therefore won't test).
Electron Shepherd wrote:
The function may be used by others, in ways that you don't know (and therefore won't test).
That argument doesn't make any sense to me. I don't see much difference between adding an optional parameter and providing a new overloaded method. The information that the new functionality is available still needs to be shared and then used appropriately. It seems to be mostly a matter of style and preference. Still, my main point in brining this topic up was that I was surprised that optional and named parameters were introduced in C# 4.0. It is something I did not expect to see.
-
rastaVnuce wrote:
you can find all references with just two clicks.
I'm guessing you don't share code between different projects, then?
That's really not the point. If the parameter is critical you don't set a default value. If it's not, it means that it makes difference for a finite number of cases which you're aware about. So, you set a default value which would be properly handled for the rest of the cases. I really don't see a place for confusion. Over a decade of experience in working with a ton of different languages and technologies, I've never had a single issue with the default parameter. On the contrary, I've missed it a lot where not available.
We are using Linux daily to UP our productivity - so UP yours!
-
I just read this[^] and thought "what on earth is going on here"? When I moved from VB.Net to C#.net, one of the big evangelistic arguments was around optional parameters as opposed to overloaded methods. I always liked optional parameters, but was prepared to give them up if the general feeling was that they where evil. Seems they aren't evil any more. I think Microsoft is just messing with my head and they will be removed in 5.0. I do like the named parameters though. I have been wanting those ever since I did some Office Automation stuff.
Two words - side effects... What I've noticed is that only ex-VB programmers seem to be excited about optional and named parameters.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001 -
Two words - side effects... What I've noticed is that only ex-VB programmers seem to be excited about optional and named parameters.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001 -
John Simmons / outlaw programmer wrote:
only ex-VB programmers seem to be excited about optional and named parameters
Not really excited, more surprised. But, yes guilty as charged. ;)
-
about 20 overloads for MessageBox.Show[^] The cases where it subtly fails are much less than where it helps. A less subtle bug would be changing
public static void DisplayName (string firstName, string lastName = null)topublic static void DisplayName (string firstName, string middleName = null, string lastName = null)ouch! But hey, we can make it, we can break it.Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server.peterchen wrote:
public static void DisplayName (string firstName, string lastName = null) ==> public static void DisplayName (string firstName, string middleName = null, string lastName = null)
That does not compile, due to ambiguity:
DisplayName( "Peter", "Not Chen" ); // Cannot be resolved to one of the two overloads..................... Life is too shor
-
peterchen wrote:
public static void DisplayName (string firstName, string lastName = null) ==> public static void DisplayName (string firstName, string middleName = null, string lastName = null)
That does not compile, due to ambiguity:
DisplayName( "Peter", "Not Chen" ); // Cannot be resolved to one of the two overloads..................... Life is too shor
I meant changing the prototype from one to another, the second argument suddenly becoming the middle name
megaadam wrote:
DisplayName( "Peter", "Not Chen" );
Who's that?
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server. -
I just read this[^] and thought "what on earth is going on here"? When I moved from VB.Net to C#.net, one of the big evangelistic arguments was around optional parameters as opposed to overloaded methods. I always liked optional parameters, but was prepared to give them up if the general feeling was that they where evil. Seems they aren't evil any more. I think Microsoft is just messing with my head and they will be removed in 5.0. I do like the named parameters though. I have been wanting those ever since I did some Office Automation stuff.
RCoate wrote:
I do like the named parameters though. I have been wanting those ever since I did some Office Automation stuff.
I've loved named parameters since I first did some Ada programming in the mid 1990s...thy'r the one thing that makes optional parameters non-evil, IMO...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p CodeProject MVP for 2010 - who'd'a thunk it!