Необязательные параметры и именованные аргументы в C#: значения по умолчанию и правила

У необязательного параметра есть значение по умолчанию в объявлении метода, поэтому вызывающий код может его опустить. Именованный аргумент передаёт значение по имени параметра, а не по позиции. Вместе они позволяют одному методу обслуживать много вариантов вызова без груды перегрузок.

using System;

class Program
{
    static void SendEmail(string to, string subject = "(no subject)", bool urgent = false, int retries = 3)
    {
        string flag = urgent ? " [URGENT]" : "";
        Console.WriteLine($"to {to}: {subject}{flag}, retries {retries}");
    }

    static void Main()
    {
        SendEmail("ana@mail.com");
        SendEmail("ben@mail.com", "Invoice #1042");
        SendEmail("cy@mail.com", urgent: true);
        SendEmail(retries: 0, to: "dev@mail.com", subject: "Build failed");
    }
}

Вывод:

to ana@mail.com: (no subject), retries 3
to ben@mail.com: Invoice #1042, retries 3
to cy@mail.com: (no subject) [URGENT], retries 3
to dev@mail.com: Build failed, retries 0

Третий вызов пропускает subject и задаёт urgent по имени; без именованных аргументов пришлось бы снова передать "(no subject)", только чтобы добраться до третьей позиции. Последний вызов передаёт все аргументы по имени в порядке, отличном от объявления, и это допустимо.

Правила для значений по умолчанию

Значение по умолчанию должно быть чем-то, что может вычислить компилятор:

• константа (3, "INFO", true, 1.5m, поле const, член перечисления)
• null для ссылочного типа или типа, допускающего null
• default(T) или new T() для типа значения T

Всё, что вычисляется во время выполнения, отвергается. Классический случай это дата:

static void Schedule(string task, DateTime at = DateTime.Now) { }
// error CS1736: Default parameter value for 'at' must be a compile-time constant

Стандартный обходной путь это параметр, допускающий null, со значением null по умолчанию, которое разрешается в теле:

using System;
using System.Collections.Generic;

class Program
{
    static void Schedule(string task, DateTime? at = null, List<string> tags = null)
    {
        DateTime when = at ?? new DateTime(2026, 1, 1, 9, 0, 0);   // stand-in for DateTime.Now
        tags = tags ?? new List<string>();
        Console.WriteLine($"{task} at {when:yyyy-MM-dd HH:mm}, tags: {tags.Count}");
    }

    static void Main()
    {
        Schedule("backup");
        Schedule("report", new DateTime(2026, 3, 15, 18, 30, 0));
        Schedule("deploy", tags: new List<string> { "prod", "api" });
    }
}

Вывод:

backup at 2026-01-01 09:00, tags: 0
report at 2026-03-15 18:30, tags: 0
deploy at 2026-01-01 09:00, tags: 2

Тот же приём подходит для коллекций: значение по умолчанию new List<string>() не является константой, поэтому по умолчанию используйте null и создавайте список внутри. Это заодно исключает ошибку с общим изменяемым значением по умолчанию, знакомую по Python, которую C# предотвращает, разрешая только константы.

Правила порядка

Сначала идут обязательные параметры, затем необязательные, а массив params (если есть) последним:

static void Log(string message, string level = "INFO", params string[] tags) { }   // OK

static void Log(string level = "INFO", string message) { }
// error CS1737: Optional parameters must appear after all required parameters

Параметры ref и out не могут быть необязательными.

При вызове позиционные аргументы заполняют параметры с начала. Именованные аргументы могут следовать за ними в любом порядке. Начиная с C# 7.2 именованный аргумент может стоять и перед позиционным, но только на своей позиции (SendEmail("a@b.c", subject: "Hi", true)); в более старых версиях все именованные аргументы должны идти в конце. Пропуск обязательного параметра, даже при указании других по имени, это ошибка компиляции.

Именованные аргументы для читаемости

Именованные аргументы полезны, даже когда ничего не является необязательным. Литералы true, false, null и голые числа ничего не говорят в месте вызова:

ResizeImage(photo, 800, 600, true, false);                                   // which is which?
ResizeImage(photo, width: 800, height: 600, keepAspect: true, upscale: false);

Переименование параметра становится несовместимым изменением для кода, который использует его имя, и об этом стоит помнить в открытой библиотеке.

Необязательные параметры и перегрузки

До C# 4 для такой же гибкости требовалась отдельная перегрузка на каждую комбинацию. Необязательные параметры сворачивают их в один метод:

// overloads
static void Connect(string host) => Connect(host, 443);
static void Connect(string host, int port) => Connect(host, port, 30);
static void Connect(string host, int port, int timeoutSeconds) { /* ... */ }

// one method with optional parameters
static void Connect(string host, int port = 443, int timeoutSeconds = 30) { /* ... */ }

Когда есть и то и другое, разрешение перегрузок предпочитает кандидата, которому не нужно подставлять значения по умолчанию:

using System;

class Program
{
    static void Greet() => Console.WriteLine("Greet()");
    static void Greet(string name = "friend") => Console.WriteLine($"Greet(string) with {name}");

    static void Main()
    {
        Greet();
        Greet("Lena");
    }
}

Вывод:

Greet()
Greet(string) with Lena

Greet() подходит под оба метода, и компилятор выбирает тот, в котором не пропущен необязательный параметр. Смешивание двух приёмов под одним именем в основном даёт вызовы, цель которых трудно предсказать, поэтому выбирайте один приём на метод.

Выбирайте перегрузки, когда вариантам нужен разный код или разные типы параметров, и необязательные параметры, когда они различаются только значениями по умолчанию.

Значения по умолчанию вшиваются в вызывающий код

Значение по умолчанию не ищется во время выполнения. Компилятор копирует его в каждое место вызова при компиляции вызывающего кода. Connect("api.shop.com") компилируется в Connect("api.shop.com", 443, 30).

Для библиотек у этого есть последствие. Допустим, версия 1 пакета поставляет Connect(string host, int timeoutSeconds = 30), а версия 2 меняет значение по умолчанию на 10. Приложение, скомпилированное с версией 1, продолжает передавать 30 после замены DLL на версию 2, пока само приложение не перекомпилируют. Добавление нового необязательного параметра в существующий открытый метод тоже ломает уже скомпилированный вызывающий код, потому что сигнатура метода изменилась, а он всё ещё ищет старую (MissingMethodException во время выполнения).

В пределах одного приложения, которое компилируется целиком, это не имеет значения. Для открытых API в пакетах NuGet проблемы избегают перегрузки (которые держат значения по умолчанию внутри библиотеки) или значение null по умолчанию, разрешаемое в теле.

Значения по умолчанию и объявленный тип

Из того же правила времени компиляции следует, что когда и интерфейс, и класс объявляют значения по умолчанию, значение берётся из типа переменной, через которую идёт вызов, а не из объекта:

using System;

interface IPrinter
{
    void Print(string text, int copies = 1);
}

class OfficePrinter : IPrinter
{
    public void Print(string text, int copies = 5)
    {
        Console.WriteLine($"printing \"{text}\" x{copies}");
    }
}

class Program
{
    static void Main()
    {
        var printer = new OfficePrinter();
        IPrinter asInterface = printer;

        printer.Print("report");
        asInterface.Print("report");
    }
}

Вывод:

printing "report" x5
printing "report" x1

Один и тот же объект, два разных значения по умолчанию. Держите значения по умолчанию одинаковыми в интерфейсе и его реализациях или объявляйте их только в одном месте.

Атрибуты сведений о вызывающем коде

На необязательных параметрах основаны и атрибуты сведений о вызывающем коде из System.Runtime.CompilerServices. Компилятор заполняет их данными о месте вызова:

using System;
using System.Runtime.CompilerServices;

class Program
{
    static void Log(string message, [CallerMemberName] string caller = "", [CallerLineNumber] int line = 0)
    {
        Console.WriteLine($"[{caller}:{line}] {message}");
    }

    static void SaveOrder()
    {
        Log("order saved");
    }

    static void Main()
    {
        Log("starting");
        SaveOrder();
    }
}

Вывод:

[Main:18] starting
[SaveOrder:13] order saved

Так библиотеки логирования записывают, откуда пришло сообщение, без того чтобы вызывающий код это набирал, а реализации INotifyPropertyChanged получают имя свойства. [CallerFilePath] так же добавляет путь к исходному файлу.