简体   繁体   中英

Passing values into methods

So let's say you have:

public void TestFishsticks()
{ 
   var fishes = GetFishstick(false);
}

private object GetFishstick(bool getBigFishes)
{
  return FishsticksManager().GetFishsticks(getBigFishes);
}

vs

public void TestFishsticks()
{ 
   var fishes = GetFishstick(getBigFishes: false);
}

private object GetFishstick(bool getBigFishes)
{
  return FishsticksManager().GetFishsticks(getBigFishes);
}

Is there any reason for this?

In my current companies codebase we seem to do both, but there seems to be no reason for one over the other. I could see a small readability improvement with the second choice, because you get to see the parameter name straight away, but you can see it via intellisense anyway?

Named arguments have mainly been introduced in C# 4.0 to improve readability. You don't actually have to use them. Some people prefer using them in some cases, others don't. It's basically up to you.

It can greatly improve readability, especially when you don't want to trigger intellisense when reading code all the time (or even worse, reviewing print-outs). Compare these two:

CalculateBMI(123, 178); // What do the numbers mean?
CalculateBMI(weightInKg: 123, heightInCentimeters: 178); // Clearer IMHO.

However, using named arguments and optional parameters together enables you to supply arguments for only a few parameters from a list of optional parameters. This capability for instance greatly facilitates calls to COM interfaces.

there seems to be no reason for one over the other

Some good reasons to use named arguments:

The code is easier to understand at a glance, particularly when the argument is false or null or 0 or "" and so on.

Named arguments work well with optional arguments. A method that takes a dozen arguments can have a simplified call site if you just need to specify a few of them.

The code is robust in the face of reordering refactorings during early development. If you make a breaking change before releasing to customers, changing:

void M(int width, int height)

to

void M(int height, int width)

then all the code that said

M(height: 123, width: 456);

will still be correct, but the code that said

M(123, 456);

will need to be updated.

Similarly, this makes code robust in the face of changing this method that specifies a rectangle:

M(int top, int bottom, int left, int right)

to this method:

M(int top, int height, int left, int width)

an obvious breaking change. Code

M(top: 10, bottom: 20, left: 30, width: 40)

will give an error when the method changes. This code will not, and changes behaviour:

M(10, 20, 30, 40);

Yes, it is mostly a readability thing. It can also come in handy when you have a long list of optional parameters, say;

public bool GetFishstick(int x = 1, int y = 2, int z = 3)
{
...
}

// Called as such: The other optional parameters (x,y) are supplied automatically.
var fish = GetFishstick(z: 10);

// Compare to the alternative where you have to provide them.
var fish = GetFishstick(1,2,10);

It should also be noted that intellisense is not always available. For example, reading code in a diff viewer like WinMerge, or occasionally notepad. The readability is still there by using the named parameters even though intellisense isn't.

What you are using here are named arguments .

They can greatly add to readability. Especially for booleans.

Consider:

var date = GetDate(2011, 2, 3);  // 'feb 3' or '2nd of march' ? 

If instead you read

var date = GetDate(year:2011, month:2, day:3); 

you know a whole lot more. It can avoid so much confusion. As a bonus, you can call it any way you like:

var date = GetDate(month:2, day:3, year:2011);  // same date.

Named arguments are only available form C#4 onwards.

Named arguments helps us not to remember or to look up the order of parameters in the parameter lists of called methods. The parameter for each argument can be specified by parameter name. It doesn't make sense (personally) since you have one parameter. In case if you have multiple then it will help to change the order or quick readability (if you don't care about method intellisense)

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM