Skip to content
  • English Deutsch

benjamin-abt.com

Performance is a feature | Cloud - AI - Azure - .NET - Sustainability

  • Home
  • Blog
  • Portfolio
    • Overview
    • Workshops & Training
    • Publications
  • Contact
  • Home
  • Blog

When to use optional arguments and parameter defaults in c#

When to use optional arguments and parameter defaults in c#
November 8, 2023 7 min read BEN ABT
.NET Csharp

This article was written in 2023. Versions, tools and recommendations may have changed since then. Newer posts are collected under .NET.

In C#, optional arguments are parameters in a method that have default values specified in the method’s declaration. This means that when you call the method, you can omit values for these optional parameters and the method will use the default values defined in its signature. Optional arguments were introduced in C# 4.0 to make it more convenient to work with methods that have a large number of parameters with sensible default values.

Here’s how you can define a method with optional arguments:

C#
1public void SomeMethod(int requiredParam, int optionalParam = 42)
2{
3    // Method implementation
4}

In the above example, optionalParam is an optional argument with a default value of 42. This means that if you call SomeMethod without specifying a value for optionalParam, it will be set to 42:

C#
1SomeMethod(10); // `requiredParam` is 10 and `optionalParam` is 42
2SomeMethod(10, 20); // `requiredParam` is 10 and `optionalParam` is 20

It’s important to note that optional arguments must be defined at the end of the parameter list and all subsequent parameters must also be optional. You cannot have a required parameter after an optional parameter.

Optional arguments can make your code more readable and allow you to provide sensible default values for parameters in cases where the caller may not need to specify them explicitly. However, you should use them judiciously to avoid making your methods overly complex and hard to understand.

When to use optional parameters

You should use optional parameters in C# when it makes your code more readable and convenient and when you want to provide default values for certain parameters in a method, but you want to allow flexibility in how those methods are called. Here are some common scenarios where using optional parameters can be beneficial:

  • Providing sensible defaults: When a method has parameters that often take on the same or default values, using optional parameters can simplify method calls by eliminating the need to specify those values explicitly. This can make the code cleaner and more concise.
  • Overloads: Instead of defining multiple overloads of a method with different parameter combinations, you can use optional parameters to provide flexibility in how the method is called. This reduces code duplication and can make your codebase more maintainable.
  • Extending existing APIs: If you’re working with libraries or APIs and you want to add new parameters to existing methods without breaking existing code, you can use optional parameters. This allows you to introduce new functionality without requiring clients to modify their code.
  • Configuration and settings: Optional parameters are often used when working with configuration or settings, where you want to provide sensible defaults but allow customization when needed. This is common in libraries and frameworks.
  • Simplifying method signatures: When you have methods with many parameters, some of which are used infrequently, you can use optional parameters to make the method signatures more concise and easier to understand.

However, it’s important to use optional parameters judiciously. Here are some considerations:

  • Clarity: While optional parameters can make code more concise, it should not come at the cost of clarity. Ensure that your code remains easy to read and understand, even when optional parameters are used.
  • Compatibility: Be mindful of the potential for breaking changes if you add, remove or change the default values of optional parameters in public APIs. Changing the defaults may affect existing code that relies on those defaults.
  • Avoiding excessive complexity: If a method has too many optional parameters, it can become challenging to work with and it may be a sign that the method needs refactoring or that it could benefit from a different design.

In summary, optional parameters are a useful feature in C# that can simplify your code and make it more user-friendly in various scenarios. However, like any language feature, they should be used with care and consideration for code readability and maintainability.

When to avoid optional parameters

While optional parameters in C# can be helpful in various situations, there are scenarios where you should avoid using them. Here are some situations where it’s better to steer clear of optional parameters:

  • Ambiguity and readability: If using optional parameters makes the method call ambiguous or less readable, it’s best to avoid them. When a method call relies on multiple optional parameters, it can be unclear which values are being passed and it might lead to unintended behavior or bugs.
  • Overly complex methods: Avoid using too many optional parameters in a single method. A method with a large number of optional parameters can become difficult to understand and maintain. In such cases, it might be better to refactor the method into multiple smaller methods or use other techniques like parameter objects.
  • API design for libraries: When designing public APIs for libraries, you should be cautious about adding or modifying optional parameters. Changing default values or introducing new optional parameters can break existing client code, leading to compatibility issues. It’s often better to use method overloads or provide configuration options through other means like builder patterns or dependency injection.
  • Mandatory parameters: If a parameter is truly required for a method to work correctly, it should not be made optional. Making such parameters optional might lead to incorrect usage of the method and it’s better to enforce the requirement by making them mandatory.
  • Type safety: Optional parameters should not compromise type safety. If optional parameters cause type-related issues, it’s better to use method overloads or other techniques to maintain strong type safety.
  • Performance considerations: Depending on how optional parameters are implemented, they might have a slight performance overhead compared to mandatory parameters. In performance-critical code, you may want to avoid optional parameters and use explicit parameter passing.
  • Unpredictable behavior: When the default values of optional parameters depend on external factors or change over time, it can lead to unpredictable behavior. Avoid using optional parameters in such cases.

In many cases, instead of relying on optional parameters, you can use method overloads, named parameters or other design patterns like the builder pattern or configuration objects to achieve the desired level of flexibility and maintain code readability. Careful consideration of your specific use case and the principles of code maintainability, readability and reliability should guide your decision to use or avoid optional parameters.

Decision by Design

A popular example is using the CancellationToken as an optional parameter.

C#
1public void SomeMethod(int requiredParam, CancellationToken ct = default) // this is design flaw
2{
3    // Method implementation
4}
5
6public void SomeMethod(int requiredParam, CancellationToken ct) // this is recommended
7{
8    // Method implementation
9}

This is certainly useful when developing things to be used in different environments. An example of this is the MediatR library, which can be used in ASP.NET Core, WPF and console applications. In ASP.NET Core the CancellationToken is supplied automatically; in WPF and console applications it must be explicitly supplied. In such scenarios, optionally specifying a pattern is useful.

However, if you are developing libraries that are used by applications etc., specifying the cancellation token parameter should be mandatory, as it is essential for proper use. Reality shows that an optional definition here leads to many developers forgetting to pass the CancellationToken. There is no compiler support. The explicit way is the safe and simple way to protect yourself from misconduct.

Conclusion

Optional parameters in C# are a useful feature that can make your code more readable and maintainable in various scenarios. However, they should be used with care and consideration for code readability and maintainability. In this article, we’ve looked at some common scenarios where optional parameters can be beneficial and some situations where it’s better to avoid them. We hope this article has helped you understand when to use optional parameters and when to avoid them in C#.

Related articles

Containerizing .NET in 2026 Without a Dockerfile

Oct 20, 2026 - 11 min read

Containerizing .NET in 2026 Without a Dockerfile

Most .NET Dockerfiles repeat the same five steps: restore, publish, select the matching Microsoft runtime image, copy the output and start …

Problem Details in ASP.NET Core and .NET 11

Oct 5, 2026 - 12 min read

Problem Details in ASP.NET Core and .NET 11

builder.Services.AddProblemDetails() registers infrastructure. It does not create an error contract. An ASP.NET Core request can fail during …

Resilience in .NET with Microsoft.Extensions.Resilience

Sep 21, 2026 - 11 min read

Resilience in .NET with Microsoft.Extensions.Resilience

Retries are the most visible resilience strategy and the easiest one to misuse. Repeating a failing call can recover from a short network …


BEN ABT

BEN ABT

Ben is Chief Engineering Officer and Principal Software Engineer at Medialesson.de, with a strong focus on .NET and Microsoft Azure. In his professional role, he designs and builds highly scalable platforms for hybrid and cloud-based scenarios. He also advises companies and C-levels on migrating to the sovereign cloud.

He runs myCSharp.de, the largest and most active German-speaking C# community forum, actively contributes to both his own and external open-source projects and regularly shares his knowledge through his blog, at community events, conferences and as a writer for technical magazines.

Let's Work Together

Looking for an experienced Platform Architect or Engineer for your next project? Whether it's cloud migration, platform modernization or building new solutions from scratch - I'm here to help you succeed.

New Platforms

Modernization

Training & Consulting

Contact Me
X Facebook LinkedIn WhatsApp
Back Next Blog Post

Open for work!

Contact Me
BEN ABT BEN ABT Software Engineer · Microsoft MVP Passionate about .NET, Azure, performance optimization and sustainable software engineering.

Medialesson GmbH Logo

Microsoft MVP Logo

Recent posts

View all
Stop Using nginx as Your Default Static File Server in Docker

Stop Using nginx as Your Default Static File Server in …

Oct 24, 2026
Containerizing .NET in 2026 Without a Dockerfile

Containerizing .NET in 2026 Without a Dockerfile

Oct 20, 2026
Problem Details in ASP.NET Core and .NET 11

Problem Details in ASP.NET Core and .NET 11

Oct 5, 2026
Resilience in .NET with Microsoft.Extensions.Resilience

Resilience in .NET with Microsoft.Extensions.Resilience

Sep 21, 2026
What Matters in ASP.NET Core 11

What Matters in ASP.NET Core 11

Sep 14, 2026

Tags

.NET (192) Csharp (96) ASP.NET Core (48) Azure (41) DevOps (17) Docker (14) Microsoft (14) EF Core (11) Microsoft MVP (11) AI (10) GitHub (10) GitHub Copilot (10) ASP.NET (9) Security (9) Synology (9) Architecture (8) Raspberry (8) Azure Functions (7) Cloudflare (7) Bicep (6)
benjamin-abt.com

About BEN

Benjamin Abt is a Software Engineer, Platform Architect and Microsoft MVP specializing in .NET, Azure, cloud architecture, performance optimization and sustainable software development.

Connect

  • Follow me on GitHub
  • Follow me on LinkedIn
  • Follow me on Mastodon
  • Microsoft MVP profile
  • Follow SchwabenCode on GitHub
  • Follow me on X

Quick Links

  • Portfolio
  • Blog
  • Workshops & Training
  • Publications
  • Get in Touch
  • Sitemap
Open for Work

© Copyright Benjamin Abt & SchwabenCode | 2011 - 2026

Content licensed under CC BY 4.0 unless otherwise noted.

  • Impressum
  • Privacy
  • Contact