10. C# (Static Typing vs Dynamic Typing)

Published: 3 days ago (February 7, 2026 at 05:33 PM EST)

4 min read

Source: Dev.to

The Real Goal of This Lesson

This lesson is not about deciding whether static typing is “better” or “worse”.

The real goal is to understand when and why the C# compiler makes decisions on your behalf, and what you gain—and give up—in return.
Once this clicks, method signatures, return types, and compiler errors stop feeling arbitrary.

How Humans Naturally Think About Types

Humans tend to think like this:

“I’m using a string now, but later I might want to use a number.”

This way of thinking is completely natural. Some languages allow this directly.

The Mental Model of Dynamically Typed Languages (Python Example)

x = "hello"
x = 10

Why this works:
The variable x has no fixed type; its identity changes based on the value it holds.

Mental model:
“What matters is what’s inside the variable right now.”
This is dynamic typing.

Why C# Refuses This

C# takes a different stance:

string x = "hello";
x = 10; // Compile-time error

This is static typing: a variable will have exactly one type for its entire lifetime.

What Static Typing Actually Means

Static typing means the compiler rejects illogical reasoning before the program is allowed to run.

Example:

string name = "Sabin";
int age = name; // Compile-time error

The compiler is effectively saying:

“This does not make sense. Do not even try to execute it.”

This is a compile‑time error, not a runtime failure.

Compile‑Time Errors vs Runtime Errors

Compile‑time errors

The program does not start.
Detected while writing code.
Include type mismatches, invalid syntax, contract violations.

The compiler warns you early.

Runtime errors

The program starts, but fails during execution.
Include null references, unexpected values, invalid operations.

These can crash the program in front of users.

Philosophy of static typing: “Fail as early as possible—ideally before the program ever runs.”

Why Method Types Are So Strict

A method declaration is a contract.

static bool IsLong(string text)

This line promises:

The method accepts a string.
The method returns a bool.

Nothing more. Nothing less.

Contract violation example 1: wrong return type

static bool IsLong(string text)
{
    return "yes"; // Compile-time error
}

Compiler logic: “You promised a boolean. This is a string. Contract violated.”

Contract violation example 2: wrong assignment target

string result = IsLong("hello"); // Compile-time error

Reason: IsLong returns bool; assigning a bool to a string is invalid.

Contract violation example 3: wrong argument type

IsLong(10); // Compile-time error

Compiler logic: “This method expects a string. A number does not fulfill the contract.”

Why This Feels Restrictive—but Isn’t

The inconvenience

Types must always match.
Less room for improvisation.

What you gain instead

Fewer runtime crashes.
Strong guarantees in large codebases.
Safer refactoring.
More accurate IDE support (autocomplete, rename, refactor).

This is one reason C# is favored in large, long‑lived systems.

Flexibility Wasn’t Removed—It Was Delayed

A common misunderstanding: “Static typing means no flexibility.”
Incorrect.

Truth: C# postpones flexibility until it can be expressed safely.

Example concept (preview):

static void Feed(Animal animal)

Dog is allowed
Cat is allowed
Snake is allowed

This is polymorphism. The pattern is always the same:

Strict rules first.
Controlled flexibility later.

Common Misunderstandings to Clear Up

Incorrect assumptions

“Using var makes C# dynamically typed.”
“C# becomes loose at runtime.”

Correct understanding

C# remains statically typed everywhere.
var still resolves to a fixed type at compile time.
Method parameters and return values are always fixed.
The compiler knows all types before execution.

Final One‑Line Summary

A statically typed language is one where the compiler actively blocks human mistakes, and method signatures are the written contracts that make this possible.