C# Method Call: Syntax, Parameters, and Return Values

When you write result = Add(3, 4); you are making a C# method call. The compiler and runtime do more than jump to the method body: they evaluate arguments, bind to the correct overload, and manage the return value. This article explains the mechanics of a C# method call, focusing on the syntax, parameter passing, and the rules that determine which method actually runs.

The Basic Syntax of a C# Method Call

A method call in C# follows a straightforward pattern: the method name, a set of parentheses, and a list of arguments separated by commas. The call must be terminated with a semicolon unless it is part of a larger expression.

int result = Add(3, 4);

For the call to compile, the method must be visible in the current scope, and the arguments must match the parameter list in type and count. If the method is static, you call it through the class name; if it is an instance method, you call it on an object.

Calculator calc = new Calculator();
int sum = calc.Add(3, 4);

The compiler checks the method signature at compile time. If the argument types do not match the parameter types, and no implicit conversion exists, you get a compile-time error. This is the first line of defense against incorrect method calls.

Passing Arguments by Value and by Reference

By default, arguments are passed by value. For value types, the method receives a copy of the value. For reference types, the method receives a copy of the reference, which still points to the same object. This means you can modify the object's state, but you cannot reassign the caller's variable to a new object unless you use ref or out.

void ChangeValue(int x)
{
    x = 10;
}

int a = 5;
ChangeValue(a); // a remains 5

When you need the method to modify the caller's variable, use the ref keyword. The variable must be initialized before the call.

void ChangeValue(ref int x)
{
    x = 10;
}

int a = 5;
ChangeValue(ref a); // a becomes 10

The out keyword is similar, but the variable does not need to be initialized before the call, and the method must assign a value to it before returning.

bool TryParse(string text, out int number)
{
    return int.TryParse(text, out number);
}

Choosing between ref and out depends on whether the method needs to read the incoming value. Use out when the method always overwrites the variable and the initial value is irrelevant.

Using Named and Optional Arguments

C# allows you to specify arguments by name rather than position. This improves readability when a method has many parameters, especially when several have default values.

void Configure(string host, int port = 80, bool useTls = true)
{
    // ...
}

Configure(host: "example.com", useTls: false);

Named arguments can be used in any order, but positional arguments must come before named ones unless you are using C# 7.2+ with named arguments in correct position. Optional parameters let you omit arguments for parameters that have a default value. The default value must be a compile-time constant.

This feature reduces the number of overloads you need, but be careful: changing a default value is a binary breaking change for callers that compiled against the old default.

How Return Values Flow Back to the Caller

A method that returns a value declares its return type in the signature. The return statement sends the value back to the caller. The caller can assign it to a variable or use it directly in an expression.

double Divide(double numerator, double denominator)
{
    if (denominator == 0)
    {
        throw new ArgumentException("Denominator cannot be zero.");
    }
    return numerator / denominator;
}

double result = Divide(10, 2);

If a method does not need to return anything, it declares void as the return type. In that case, the return statement can be used without a value to exit early, but it is optional at the end of the method.

The runtime uses the call stack to pass the return value back to the caller. For small value types, the value is often returned in a CPU register; larger structs may be returned via a hidden memory location. This is an implementation detail, but it explains why returning a large struct by value can be more expensive than returning a reference.

Method Overload Resolution at the Call Site

When you call a method that has multiple overloads, the compiler must decide which one to invoke. It uses the argument types and the set of available overloads to find the best match. The rules are based on the number of parameters, the types of the arguments, and any implicit conversions that are available.

void Print(int number) { }
void Print(string text) { }

Print(42);   // calls Print(int)
Print("hi"); // calls Print(string)

If no overload is applicable, you get a compile-time error. If more than one overload is equally good, the compiler reports an ambiguity. For example, calling Print(null) with overloads for string and object is ambiguous because null can convert to both.

Understanding overload resolution helps you predict which method will run when you pass arguments that could match multiple signatures. This is especially important when you have overloads that differ only by parameter type or by optional parameters.

Common Mistakes When Calling Methods

One common mistake is passing arguments in the wrong order when the types are similar. For example, a method that takes (int width, int height) can be accidentally called as (height, width) without a compile error. Named arguments reduce this risk.

Another mistake is forgetting to use ref or out when the method expects them. The compiler will reject the call, but the error message can be confusing if you are not familiar with the signature.

Optional parameters can also cause subtle issues. If you omit an argument, the default value is used. If the default value is not what you expect, the behavior may be wrong. For instance, a method that defaults a timeout to 30 seconds might be called without a timeout when the caller intended to disable it.

Finally, overload resolution with params arrays can surprise developers. A call like Print(new int[] { 1, 2, 3 }) may match both a params int[] overload and a single int[] parameter overload, leading to an ambiguity error.

Performance and Allocation Considerations

Method calls are not free. Each call typically allocates a stack frame, which involves saving the return address and adjusting the stack pointer. For most applications, this overhead is negligible, but in tight loops it can matter.

The JIT compiler can inline small methods, eliminating the call overhead entirely. Inlining is more likely for simple methods that do not contain loops or exception handling. You can use [MethodImpl(MethodImplOptions.AggressiveInlining)] to hint the JIT, but it is not a guarantee.

Passing large structs by value copies the entire struct into the argument. If you do this repeatedly, the copy cost can become significant. Using ref or in avoids the copy, but you must be careful about side effects. The in parameter passes a read-only reference, which is useful for large, immutable structs.

Another consideration is the allocation of delegate instances when you use method groups. Converting a method to a delegate allocates a new delegate object each time, unless the compiler can cache it. In high-frequency code, this can cause GC pressure. Reusing a delegate instance or using a static lambda can reduce allocations.

These performance details are not something you should optimize prematurely, but they matter when you are writing code that is called millions of times per second, such as in a game loop or a high-throughput service.