Named arguments in C# allow you to pass method arguments by writing the parameter name explicitly. Instead of relying only on argument position, you can say which parameter each value belongs to. This makes method calls more readable, especially when a method has multiple parameters of the same type or several optional parameters.
Named arguments do not change what a method does. They change how clearly the call expresses intent. They are especially useful in APIs, constructors, configuration-style methods, and calls with Boolean or numeric values that would otherwise be hard to understand.
What Are Named Arguments in C#?
A named argument specifies the parameter name followed by a colon and the value. This lets the compiler bind the value to that parameter directly.
void PrintUser(string name, int age)
{
Console.WriteLine($"{name} is {age} years old");
}
PrintUser(name: "Asha", age: 25);The call clearly shows that "Asha" is the name and 25 is the age. This is simple here, but the value becomes stronger as method calls become more complex.
Syntax of Named Arguments
MethodName(parameterName: value);The parameter name must match the name in the method declaration. If the name is wrong, the compiler reports an error. Named arguments are checked at compile time, so they are safe and refactor-friendly when used correctly.
Named Arguments Improve Readability
Named arguments are helpful when values are not self-explanatory. Boolean arguments are a common example because true or false alone does not explain the meaning.
SaveFile("report.txt", overwrite: true);
SendEmail("admin@example.com", highPriority: false);These calls are easier to understand than SaveFile("report.txt", true) or SendEmail("admin@example.com", false). The parameter name documents the meaning at the call site.
Changing Argument Order
Named arguments can be used to pass values in a different order from the method declaration. This works because the parameter names identify the destination.
void CreateUser(string name, string role, bool isActive)
{
Console.WriteLine($"{name}, {role}, {isActive}");
}
CreateUser(isActive: true, role: "Admin", name: "Asha");This is valid, but changing order too much can make calls harder to scan. Named arguments should improve clarity, not create surprising call layouts.
Named Arguments with Optional Parameters
Named arguments are very useful with optional parameters. They allow you to skip optional parameters that should keep their default values and set only the value you care about.
void CreateReport(string title, bool includeCharts = true, bool includeSummary = true)
{
Console.WriteLine(title);
}
CreateReport("Sales Report", includeSummary: false);Here, includeCharts keeps its default value, while includeSummary is set explicitly. This would be awkward without named arguments.
Positional and Named Arguments Together
C# allows positional and named arguments together, but there are ordering rules. Positional arguments generally come first. Named arguments can follow them for clarity.
CreateReport("Monthly Report", includeCharts: false);This style is common. The required title is passed positionally, and the optional setting is passed by name.
Named Arguments in Constructors
Named arguments can also be used with constructors. This is helpful when constructor parameters are similar or when object creation needs to be self-explanatory.
class Rectangle
{
public Rectangle(int width, int height)
{
Console.WriteLine($"{width} x {height}");
}
}
Rectangle rectangle = new Rectangle(width: 800, height: 600);The call clearly identifies width and height. This reduces mistakes when both parameters have the same type.
Named Arguments vs Positional Arguments
| Feature | Named Arguments | Positional Arguments |
|---|---|---|
| Binding | By parameter name | By position |
| Readability | Better for unclear values | Shorter for obvious values |
| Best for | Booleans, optional parameters, same-type values | Simple calls with clear order |
| Risk | Can be verbose if overused | Can hide meaning in complex calls |
Use positional arguments for simple and obvious calls. Use named arguments when they make the call more readable.
Named Arguments with Same-Type Parameters
Named arguments are especially useful when a method has multiple parameters of the same type. Without names, it is easy to pass values in the wrong order and still compile successfully.
void MoveFile(string sourcePath, string destinationPath)
{
Console.WriteLine($"Moving {sourcePath} to {destinationPath}");
}
MoveFile(sourcePath: "old.txt", destinationPath: "new.txt");Both parameters are strings, so a positional call can be accidentally reversed. Named arguments make the direction clear and reduce the chance of subtle bugs.
Named Arguments and Refactoring
Named arguments depend on parameter names. If a method parameter is renamed, calls using that parameter name must also be updated. Modern IDEs usually handle this during refactoring, but public APIs need extra care because external callers may depend on those names.
For private application code, this is rarely a serious issue. For public libraries, parameter names become part of the practical API surface when callers use named arguments. Renaming a public parameter can break source compatibility for users who call the method by name.
Named Arguments with Method Overloading
Named arguments can help readability with overloaded methods, but they do not magically fix confusing overload design. The compiler still chooses the method based on overload resolution rules, parameter names, and argument types.
void Print(string text, int count)
{
Console.WriteLine(text);
}
void Print(string text, bool uppercase)
{
Console.WriteLine(uppercase ? text.ToUpper() : text);
}
Print(text: "hello", uppercase: true);The named argument uppercase makes it clear which overload is intended. Still, if overloads become too similar, clearer method names may be better.
Named Arguments with Default Values
Named arguments and optional parameters are often used together. This combination is useful when a method has several default settings but the caller wants to override only one or two of them.
void Search(string query, int page = 1, int pageSize = 20, bool includeArchived = false)
{
Console.WriteLine(query);
}
Search("csharp", includeArchived: true);The call keeps the default page and page size, but explicitly includes archived results. This is much clearer than passing several positional values just to reach the last parameter.
Named Arguments vs Options Object
If a method needs many named arguments to be readable, the method may have too many parameters. An options object can group related settings and make the API easier to extend later.
class SearchOptions
{
public int Page { get; set; } = 1;
public int PageSize { get; set; } = 20;
public bool IncludeArchived { get; set; }
}
void Search(string query, SearchOptions options)
{
Console.WriteLine(query);
}Named arguments are good for a few clarifying values. Options objects are better when the number of settings grows or when settings are reused across multiple calls.
Named Arguments with Records and Object Initializers
Modern C# often uses records, object initializers, and options types to avoid long parameter lists. Named arguments still matter, especially for constructors and positional records, but object initializers can be clearer for many optional settings.
var options = new SearchOptions
{
PageSize = 50,
IncludeArchived = true
};This style gives each setting a visible name and avoids relying on parameter order. It is often easier to maintain when configuration grows.
When Named Arguments Hurt Readability
Named arguments are not always better. If a method call is already obvious, naming every argument can make the code noisy. For example, Math.Max(10, 20) is clear enough without names. Adding names to every simple call can reduce readability instead of improving it.
The best use of named arguments is selective. Use them where they explain unclear values, not as a rule for every method call.
Style Rule for Named Arguments
A practical style rule is to use named arguments for Boolean values, optional values being skipped, repeated same-type values, and constructor calls where parameter meaning is not obvious. For simple methods with one or two clear arguments, positional arguments are usually fine.
This keeps code clean without making it verbose. The goal is to make the call site explain itself.
Named Arguments and Public API Compatibility
In public APIs, parameter names matter more than many beginners expect. If callers use named arguments, changing a parameter name can break their source code even if the parameter type stays the same. This is why library authors should treat public parameter names as part of the API design.
For internal code, renaming is usually safe because the whole project can be refactored together. For libraries used by other projects, parameter names should be stable, meaningful, and reviewed carefully before release.
Named Arguments and Self-Documenting Code
Named arguments can make code self-documenting. They place the meaning of a value directly beside the value. This is useful during code review because reviewers can understand intent without jumping to the method definition.
Retry(operation, maxAttempts: 3, delayMilliseconds: 500);This call clearly says what 3 and 500 mean. Without names, those numbers would be magic values at the call site.
Named Arguments and Code Reviews
Named arguments are helpful in code reviews because they reduce guesswork. A reviewer can quickly see whether a call is passing the right value to the right parameter. This is especially useful when several parameters have the same type, such as multiple strings, integers, or Boolean flags.
They are not a replacement for good method design, but they are a useful tool for making important calls safer and clearer.
Use them where they remove doubt, especially around Boolean flags, numeric settings, and same-type parameter lists. Skip them where the method call is already obvious and compact.
Common Mistakes with Named Arguments
- Overusing named arguments when the call is already obvious.
- Changing argument order in a way that makes calls harder to scan.
- Using named arguments to hide a method with too many parameters.
- Depending heavily on parameter names in public APIs without considering compatibility.
- Using unclear parameter names that do not improve readability.
Best Practices for Named Arguments in C#
Use named arguments when they clarify the meaning of values, especially Boolean arguments, optional parameters, and repeated same-type parameters. Avoid using them as a workaround for poor method design. If a method needs many named arguments to be understandable, an options object may be better.