Parâmetros opcionais e argumentos nomeados em C#: padrões e regras

Um parâmetro opcional tem um valor padrão na declaração do método, então quem chama pode omiti-lo. Um argumento nomeado passa um valor pelo nome do parâmetro em vez da posição. Juntos, eles permitem que um método atenda a muitas formas de chamada sem uma pilha de sobrecargas.

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");
    }
}

Saída:

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

A terceira chamada pula subject e define urgent pelo nome; sem argumentos nomeados, ela teria que passar "(no subject)" de novo só para chegar à terceira posição. A última chamada passa todos os argumentos pelo nome, em uma ordem diferente da declaração, o que é válido.

Regras para valores padrão

Um valor padrão precisa ser algo que o compilador consiga calcular:

• uma constante (3, "INFO", true, 1.5m, um campo const, um membro de enum)
• null para um tipo de referência ou anulável
• default(T), ou new T() para um tipo de valor T

Qualquer coisa avaliada em tempo de execução é rejeitada. O caso clássico é uma data:

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

A solução padrão é um parâmetro anulável com null como padrão, resolvido no corpo:

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" });
    }
}

Saída:

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

O mesmo truque serve para coleções: um padrão new List<string>() não é uma constante, então use null como padrão e crie a lista dentro do método. Isso também evita o bug do padrão mutável compartilhado do Python, que C# descarta ao aceitar só constantes.

Regras de ordem

Os parâmetros obrigatórios vêm primeiro, os opcionais depois, e um array params (se houver) por último:

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

Parâmetros ref e out não podem ser opcionais.

Na chamada, os argumentos posicionais preenchem os parâmetros a partir do começo. Argumentos nomeados podem vir depois deles em qualquer ordem. Desde o C# 7.2, um argumento nomeado também pode aparecer antes de um posicional, mas só quando está na sua própria posição (SendEmail("a@b.c", subject: "Hi", true)); em versões mais antigas, os argumentos nomeados precisam vir todos no final. Deixar de fora um parâmetro obrigatório, mesmo nomeando outros, é um erro de compilação.

Argumentos nomeados para legibilidade

Argumentos nomeados são úteis mesmo quando nada é opcional. Literais true, false, null e números soltos não dizem nada no ponto da chamada:

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

Renomear um parâmetro passa a ser uma mudança que quebra quem usa o nome, o que vale lembrar em uma biblioteca pública.

Parâmetros opcionais versus sobrecargas

Antes do C# 4, a mesma flexibilidade exigia uma sobrecarga por combinação. Parâmetros opcionais reúnem tudo em um método:

// 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) { /* ... */ }

Quando os dois existem, a resolução de sobrecarga prefere um candidato que não precise de nenhum padrão preenchido:

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");
    }
}

Saída:

Greet()
Greet(string) with Lena

Greet() corresponde aos dois métodos, e o compilador escolhe o que não tem parâmetro opcional omitido. Misturar as duas técnicas no mesmo nome costuma gerar chamadas cujo destino é difícil de prever, então escolha uma por método.

Escolha sobrecargas quando as variantes precisam de código ou tipos de parâmetro diferentes, e parâmetros opcionais quando só diferem nos valores padrão.

Os padrões ficam gravados em quem chama

Um valor padrão não é consultado em tempo de execução. O compilador o copia para cada ponto de chamada quando o código que chama é compilado. Connect("api.shop.com") compila como Connect("api.shop.com", 443, 30).

Isso tem uma consequência para bibliotecas. Suponha que a versão 1 de um pacote traga Connect(string host, int timeoutSeconds = 30) e que a versão 2 mude o padrão para 10. Uma aplicação compilada contra a versão 1 continua passando 30 depois que você coloca a DLL da versão 2, até a própria aplicação ser recompilada. Adicionar um novo parâmetro opcional a um método público existente também quebra quem já foi compilado, porque a assinatura do método mudou e eles ainda procuram a antiga (uma MissingMethodException em tempo de execução).

Dentro de uma aplicação compilada como um todo, isso nunca importa. Para APIs públicas em pacotes NuGet, sobrecargas (que mantêm os padrões dentro da biblioteca) ou um padrão null resolvido no corpo evitam o problema.

Padrões e o tipo declarado

A mesma regra de tempo de compilação faz com que, quando uma interface e uma classe declaram padrões, o padrão venha do tipo da variável pela qual você chama, não do objeto:

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");
    }
}

Saída:

printing "report" x5
printing "report" x1

O mesmo objeto, dois padrões diferentes. Mantenha os valores padrão idênticos entre uma interface e suas implementações, ou declare-os em um só lugar.

Atributos de informação do chamador

Parâmetros opcionais também são a base dos atributos de informação do chamador em System.Runtime.CompilerServices. O compilador os preenche com detalhes do ponto de chamada:

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();
    }
}

Saída:

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

É assim que bibliotecas de log registram de onde veio uma mensagem sem que quem chama precise digitar isso, e é assim que implementações de INotifyPropertyChanged obtêm o nome da propriedade. [CallerFilePath] adiciona o caminho do arquivo fonte da mesma forma.