C# Scope and How Values Move

A local variable exists from its declaration to the end of its containing block, subject to C#'s definite-assignment rules. A variable declared inside an if block cannot be read afterward because that branch may not run and because the name's scope ends at the closing brace.

Narrow scope reduces accidental interaction. A loop counter belongs inside the loop when no later code needs it. A calculated result belongs outside a branch only when all relevant paths assign it. Do not widen a variable's scope merely to avoid thinking about ownership.

if (temperature < 0)
{
  string warning = "Ice risk";
  Console.WriteLine(warning);
}

// warning is not in scope here

C# passes arguments by value unless ref, out, or in explicitly changes that rule. For an int, the copied value is the number itself. Assigning to the parameter changes only that local copy, not the caller's variable.

Returning the new value makes the data flow explicit. A caller can choose to store it or ignore it. ref can allow a method to assign the caller's variable, but it creates a tighter relationship and is unnecessary for most ordinary transformations.

using System;

class Program
{
  static int AddBonus(int score)
  {
      score += 10;
      return score;
  }

  static void Main()
  {
      int original = 50;
      int withBonus = AddBonus(original);

      Console.WriteLine(original);
      Console.WriteLine(withBonus);
  }
}

50
60

Classes, arrays, strings, and List<T> are reference types. A variable holding one of them contains a reference to an object. Passing it by value copies that reference. The caller and method then have separate variables, but both references can point to the same mutable object.

That is why AddGuest can change the shared List. Reassigning the parameter to a new list would only change the method's local reference, but calling Add on the existing object changes the object both references reach. Strings are reference types too, but their immutability prevents character-by-character mutation.

A method named GetGuestCount should not quietly remove guests. Names, return types, and parameters should help a caller predict side effects. When practical, return a new value rather than mutating distant shared state. When mutation is the point, use an action name such as AddGuest and keep ownership clear.

Fields and properties have wider lifetimes than local variables and can make several methods depend on shared state. They are useful inside well-designed objects, but global mutable state makes tests and reasoning difficult. Start with locals and explicit parameters, then move state into an object that owns the relevant rules.