Named arguments (parameters) as a readability aid

Question

A long time ago I programmed a lot in ADA, and it was normal to name arguments when invoking a function - SomeObject.DoSomething(SomeParameterName => someValue);

Now that C# supports named arguments, I'm thinking about reverting to this habit in situations where it might not be obvious what an argument means.

You might argue that it should always be obvious what an argument means, but if you have a boolean argument, and callers are passing in "true" or "false" then qualifying the value with the name makes the call site more readable.

contentFetcher.DownloadNote(note, manual : true);

I guess I could create Enums instead of using true or false (Manual, Automatic in this case).

What do you think about occasionally using named arguments to make code easier to read?

Answer 1

This was suggested in the development of C++, and Stroustrup discusses it in his "Design and Evolution of C++", pages 153 and following. The proposal was well-formed, and drew on prior experience with Ada. It wasn't adopted.

The biggest reason was that nobody wanted to encourage functions with large numbers of parameters. Each additional feature in a language costs something, and there was no desire to add a feature to make it easier to write bad programs.

It also raised questions of what the canonical parameter names were, particularly in the usual header and code file convention. Some organizations had longer and more descriptive parameter names in the .h file, and shorter and easier to type names in the .cpp file (substitute file suffixes as desired). Requiring that these be the same would be an additional cost on compilation, and getting names mixed up between source files could cause subtle bugs.

It can also be handled by using objects rather than function calls. Instead of a GetWindow call with a dozen parameters, create a Window class with a dozen private variables, and add setters as necessary. By chaining the setters, it's possible to write something like my_window.SetColor(green).SetBorder(true).SetBorderSize(3);. It's also possible to have different functions with different defaults that call the function that actually does the work.

If you're just worried about the documentation effect of contentFetcher.DownloadNote(note, manual : true);, you can always write something like contentFetcher.DownloadNote(note, /* manual */ true);, so it's not even very helpful in documentation.

Answer 2

I think this is issue of making bad code more readable, rather than “best practice”.

Having a method (or contractor) that takes 20 parameters is a “bad smell” and is likely to be due to a problem in your design. However if I am forced to work on code when methods take a lot of parameters, then named parameter make the code less hard to understand.

When methods only have 1 or 2 parameters and it is clear from the method name what the parameter are, then named parameter add nothing. This is the ideal case to be in.

If all the code you work on is written as par the “clean code” book, then you will have very little use for named parameters, however we live in the real world.

Answer 3

I agree that adding the parameter name makes it more readable. However, most of the books I've read seem to consider boolean switches to be a bad practice. I sometimes do this:

public Content DownloadNote(Note note)
{
    return downloadNote(note, manual: false);
}

public Content DownloadNoteManually(Note note)
{
    return downloadNote(note, manual: true);
}

That does give you more flexibility when implementing your API. It also allows you to control the case where you have multiple boolean switches, but not all of them can be active at the same time.

Answer 4

I'm a big believer in named parameters in situations where the types and semantics are not clear from the name of the method. My experience is that few folks read the documentation.

That being said, named parameters should not be an alternative to making sensible argument lists, using helper objects (to "tie" together semantically related arguments), and using enumerations where relevant.

Answer 5

I think this is more useful in non-OO languages, where you may have one function that has to do something in several slightly different ways, and the way it determines what to do is based on parameter values. In the OOP world, we would just overload the function, but when that's not possible then you wind up passing a bunch of flags (or a bunch of values, and whether or not they're passed is the flag).

I think it's more readable, to an extent; but as others have mentioned, having many parameters is a code smell, so I don't see a whole lot of use for this in an object-oriented language like C#.