Value types vs reference types

The most important mental model in C#

Many confusing bugs come down to one question: when I copy this variable, do I get a new thing, or another name for the same thing? The answer depends on whether the type is a value type or a reference type.

Picture it

 Value type                     Reference type
 int a = 5;                     var p = new Person("Ada");
 
 ┌─────┐                        ┌─────┐       ┌──────────────┐
 │a: 5 │                        │p: ●─┼──────▶│ Person       │
 └─────┘                        └─────┘       │ Name = "Ada" │
                                              └──────────────┘
 int b = a;                     var q = p;
 
 ┌─────┐ ┌─────┐                ┌─────┐
 │a: 5 │ │b: 5 │  two copies    │p: ●─┼──┐    ┌──────────────┐
 └─────┘ └─────┘                └─────┘  ├───▶│ Person       │
                                ┌─────┐  │    │ Name = "Ada" │
                                │q: ●─┼──┘    └──────────────┘
                                └─────┘   one object, two references

• A value-type variable contains the data itself. Assignment copies the data.
• A reference-type variable contains a reference (an address). Assignment copies the reference, so both variables point to the same object.

var p = new Person("Ada");
var q = p;
q.Name = "Grace";
Console.WriteLine(p.Name);    // Grace — p and q are the same object

Step through it yourself — including what happens when a method is called and when the last reference disappears:

1int age = 36;
2var ada = new Person("Ada");
3var alias = ada;
4alias.Name = "Grace";
5Rename(ada);
6ada = null;
7alias = null;
8 
9void Rename(Person p)
10{
11    p.Name = "Linus";
12}

Passing to methods

Arguments are always copied (unless you use ref). What gets copied is the variable's content — the value, or the reference:

void Birthday(Person person) => person.Age++;        // modifies the shared object ✅ visible to caller
void Replace(Person person) => person = new Person("Bob");   // re-points the local copy ❌ invisible
 
void Increment(int n) => n++;                         // modifies a copy ❌ invisible

The rule of thumb: through a reference you can modify the object, but you can't make the caller's variable point somewhere else.

Arrays and lists are references too

This catches everyone at least once:

int[] original = { 1, 2, 3 };
int[] copy = original;           // NOT a copy — the same array
copy[0] = 99;
Console.WriteLine(original[0]);  // 99
 
int[] realCopy = (int[])original.Clone();   // or original.ToArray() with LINQ

Equality: same object, or same value?

var a = new Person("Ada");
var b = new Person("Ada");
Console.WriteLine(a == b);                    // False — different objects (classes default to reference equality)
Console.WriteLine(ReferenceEquals(a, a));     // True
 
Console.WriteLine("hi" == "h" + "i");         // True — string compares text
Console.WriteLine(new Point(1, 2) == new Point(1, 2));   // True for records and record structs

Strings: reference type, value behavior

string is a class, but it's immutable: no method can change a string's contents. So even though variables share references, nobody can modify the shared string, and it behaves like a value. Its == compares text.

Where they live (briefly)

You'll often hear "value types live on the stack, reference types on the heap". It's a useful first approximation: objects are allocated on the managed heap and cleaned up by the garbage collector, while local value-type variables usually sit on the stack. Track 5 goes into the details — including the exceptions to that rule.

Try it

Key takeaways

• Value types (numbers, bool, structs, enums) are copied on assignment.
• Reference types (classes, records, arrays, lists, strings) share one object between copies.
• Methods can modify objects passed to them, but not the caller's variables (without ref).
• Classes compare by reference by default; records, structs and strings compare by value.