Constants and readonly fields in C Sharp (C#) - Deep Dive

Overview - Constants and readonly fields

What is it?

Constants and readonly fields are ways to store values that do not change after being set. Constants are fixed values known at compile time and cannot be changed later. Readonly fields can be assigned once during runtime, usually in a constructor, and then remain unchanged. Both help protect important data from accidental modification.

Why it matters

Without constants and readonly fields, programs would risk changing values that should stay fixed, causing bugs and unpredictable behavior. They make code safer and clearer by signaling which values are meant to stay the same. This helps developers avoid mistakes and makes the program easier to understand and maintain.

Where it fits

Before learning constants and readonly fields, you should understand variables and basic data types in C#. After this, you can learn about immutability, static members, and design patterns that rely on fixed values.

Mental Model

Core Idea

Constants and readonly fields are like labels on boxes that say 'Do not change this'—constants are permanent labels stuck at the start, while readonly labels can be set once when the box is packed.

Think of it like...

Imagine you have a recipe book. A constant is like a printed ingredient list that never changes, while a readonly field is like a handwritten note you add once when cooking and then keep unchanged for that meal.

┌───────────────┐       ┌───────────────┐
│   Constant    │       │  Readonly     │
│  (fixed at   │──────▶│ (set once at  │
│ compile time) │       │ runtime, then │
│               │       │  locked)      │
└───────────────┘       └───────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding Variables and Immutability

Concept: Introduce variables and the idea that some values should not change after being set.

Variables in C# hold data that can change. Sometimes, we want to keep values fixed to avoid mistakes. Constants and readonly fields help us do that by preventing changes after assignment.

Result

Learners understand why some data should stay fixed and the need for special ways to enforce this.

Knowing why immutability matters helps you appreciate constants and readonly fields as tools to protect important data.

2

Foundation

Declaring Constants in C#

Concept: Learn how to declare constants and their basic rules.

Use the keyword 'const' to declare a constant. It must be assigned a value when declared, and that value cannot change. Constants are implicitly static and belong to the type, not instances. Example: const int DaysInWeek = 7;

Result

You can create fixed values that the compiler knows and enforces as unchangeable.

Understanding that constants are compile-time fixed values helps prevent accidental changes and improves code clarity.

3

Intermediate

Using Readonly Fields for Runtime Constants

Concept: Introduce readonly fields that can be set once at runtime, usually in constructors.

Declare readonly fields with the 'readonly' keyword. They can be assigned when declared or inside a constructor. After that, they cannot be changed. Example: readonly DateTime creationTime; public MyClass() { creationTime = DateTime.Now; }

Result

You can have values that are fixed after object creation but can differ between instances.

Knowing readonly fields allow runtime assignment gives flexibility for values that depend on runtime information but still need protection.

4

Intermediate

Differences Between Constants and Readonly Fields

🤔Before reading on: Do you think constants and readonly fields can both be assigned at runtime? Commit to your answer.

Concept: Clarify the key differences in assignment time, usage, and behavior.

Constants are assigned once at compile time and are static by default. Readonly fields can be assigned once at runtime, typically in constructors, and can be instance-specific. Constants can only hold simple types or strings, while readonly fields can hold complex types.

Result

You can choose the right tool depending on when and how you want to assign fixed values.

Understanding these differences prevents misuse and helps write clearer, safer code.

5

Advanced

Constants, Readonly, and Static Together

🤔Before reading on: Can a readonly field be static? What about a constant? Commit to your answer.

Concept: Explore combining readonly and static keywords and how constants relate to static members.

Constants are implicitly static, so you don't write 'static' with them. Readonly fields can be static or instance-level. Static readonly fields are assigned once per type, often used for values that need runtime initialization but shared across all instances. Example: static readonly DateTime startupTime = DateTime.Now;

Result

You can create fixed values shared by all instances but set at runtime.

Knowing how static and readonly combine helps manage shared immutable data initialized at runtime.

6

Expert

Performance and Versioning Implications

🤔Before reading on: Do you think changing a constant value in a library always updates all dependent projects automatically? Commit to your answer.

Concept: Understand how constants and readonly fields affect performance and versioning in compiled code.

Constants are replaced by their values at compile time, so changing a constant in a library requires recompiling dependent projects to see updates. Readonly fields are accessed at runtime, so changes in libraries reflect immediately without recompilation. Constants can improve performance but risk versioning issues.

Result

You can make informed decisions about when to use constants or readonly fields considering maintenance and performance.

Knowing the tradeoff between compile-time substitution and runtime access prevents subtle bugs in multi-project solutions.

Under the Hood

Constants are replaced by their literal values during compilation, meaning the compiled code contains the actual value, not a reference. Readonly fields are stored as normal fields but can only be assigned once, enforced by the compiler and runtime. Static readonly fields are initialized once per type, often in static constructors.

Why designed this way?

Constants were designed for fixed values known at compile time to optimize performance and clarity. Readonly fields were introduced to allow immutable values that depend on runtime information, providing flexibility while maintaining safety. This design balances efficiency with practical programming needs.

┌───────────────┐
│ Source Code   │
│ const int x=5 │
│ readonly int y│
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Compiler      │
│ replaces x=5  │
│ enforces y=once│
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Compiled Code │
│ uses literal 5│
│ stores y field│
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Can you assign a new value to a readonly field anywhere in the code after construction? Commit yes or no.

Common Belief: Readonly fields can be changed anytime like normal variables.

Reality: Readonly fields can only be assigned once, either at declaration or inside a constructor. After that, they cannot be changed.

Why it matters: Trying to change readonly fields later causes compile errors and misunderstanding this leads to incorrect code design.

Quick: Does changing a constant value in a library automatically update all projects using it without recompiling? Commit yes or no.

Common Belief: Changing a constant in a library updates all dependent projects immediately.

Reality: Constants are replaced at compile time, so dependent projects must be recompiled to see changes.

Why it matters: Failing to recompile dependent projects causes bugs where old constant values persist unexpectedly.

Quick: Can constants hold complex objects like lists or classes? Commit yes or no.

Common Belief: Constants can store any type of data, including complex objects.

Reality: Constants can only hold primitive types, enums, or strings. Complex objects require readonly fields.

Why it matters: Misusing constants for complex data leads to compile errors and confusion about immutability.

Quick: Are constants and readonly fields interchangeable in all cases? Commit yes or no.

Common Belief: Constants and readonly fields can be used interchangeably without issues.

Reality: They serve different purposes: constants are compile-time fixed, readonly fields are runtime fixed. Using one instead of the other can cause bugs or design problems.

Why it matters: Choosing the wrong one can cause versioning issues, runtime errors, or inflexible code.

Expert Zone

1

Readonly fields can be assigned in multiple constructors, allowing different initialization paths while still enforcing immutability after construction.

2

Static readonly fields are often used for expensive-to-calculate constants that depend on runtime data, balancing performance and flexibility.

3

Constants embedded in assemblies can cause subtle bugs in distributed systems if dependent assemblies are not rebuilt after changes.

When NOT to use

Avoid constants when values might change in future versions or depend on runtime data; use readonly fields instead. Do not use readonly fields if values need to change after construction; use regular variables or properties. For configuration data, consider external files or databases rather than constants or readonly fields.

Production Patterns

In production, constants are used for fixed values like mathematical constants or fixed strings. Readonly fields are used for timestamps, unique IDs, or configuration values set at startup. Static readonly fields often hold shared immutable data initialized once, such as cached settings or computed constants.

Connections

Immutability in Functional Programming

Builds-on

Understanding constants and readonly fields helps grasp immutability principles that prevent side effects and improve reliability in functional programming.

Version Control and Software Maintenance

Related concept

Knowing how constants affect versioning helps manage software updates and dependencies effectively in large projects.

Legal Contracts and Terms

Analogy in a different field

Just like constants and readonly fields fix terms that cannot be changed, legal contracts fix agreements that parties must follow, showing how fixed rules maintain order.

Common Pitfalls

#1 Trying to assign a new value to a readonly field outside the constructor.

Wrong approach:

public class Example {
readonly int x;
public void Change() {
x = 10; // Error: cannot assign
}
}

Correct approach:

public class Example {
readonly int x;
public Example() {
x = 10; // Allowed
}
}

Root cause:

Misunderstanding that readonly fields can only be assigned once during declaration or construction.

#2 Changing a constant value in a library but not recompiling dependent projects.

Wrong approach:

// Library code
public const int MaxValue = 100; // changed to 200

// Dependent project uses old value without recompilation

Correct approach:

// After changing constant, recompile all dependent projects to update embedded values.

Root cause:

Not realizing constants are replaced at compile time, requiring recompilation to propagate changes.

#3 Declaring a constant with a complex type like a list.

Wrong approach:

public const List Numbers = new List {1, 2, 3}; // Error

Correct approach:

public readonly List Numbers = new List {1, 2, 3};

Root cause:

Believing constants can hold complex objects, which is not allowed in C#.

Key Takeaways

Constants are fixed values set at compile time and cannot change, making them efficient but less flexible.

Readonly fields can be assigned once at runtime, usually in constructors, allowing immutable but instance-specific data.

Constants are implicitly static, while readonly fields can be static or instance-level, providing different usage scenarios.

Changing constants in libraries requires recompiling dependent projects to avoid stale values and bugs.

Choosing between constants and readonly fields depends on when and how values are assigned and whether they need to be shared or instance-specific.

Practice

1. What is the main difference between const and readonly fields in C#?

easy

A. const and readonly are exactly the same and can be used interchangeably.

B. readonly values are set at compile time and cannot change; const values can be set at runtime but only once.

C. const values are set at compile time and cannot change; readonly values can be set at runtime but only once.

D. const values can be changed anytime; readonly values cannot be changed.

Solution

1. Step 1: Understand const behavior

   const fields are fixed at compile time and cannot be changed later.

2. Step 2: Understand readonly behavior

   readonly fields can be assigned once at runtime, usually in a constructor, and then cannot change.

3. Final Answer:

   const values are set at compile time and cannot change; readonly values can be set at runtime but only once. -> Option C

4. Quick Check:

   const fixed at compile, readonly set once at runtime [OK]

Hint: Remember: const fixed early, readonly set once later [OK]

Common Mistakes:

• Thinking readonly can be changed multiple times
• Confusing when const values are set
• Assuming const can be assigned in constructors

2. Which of the following is the correct way to declare a constant integer named MaxValue with value 100 in C#?

easy

A. readonly int MaxValue = 100;

B. const int MaxValue = 100;

C. int const MaxValue = 100;

D. static readonly MaxValue = 100;

Solution

1. Step 1: Check correct syntax for constant declaration

   In C#, const must be followed by type, then name and value, like const int MaxValue = 100;.

2. Step 2: Identify incorrect options

   readonly requires a type and cannot be declared like a constant; int const is invalid syntax in C#; static readonly requires a type and cannot omit it.

3. Final Answer:

   const int MaxValue = 100; -> Option B

4. Quick Check:

   const syntax = const type name = value; [OK]

Hint: const must include type before name [OK]

Common Mistakes:

• Using 'int const' instead of 'const int'
• Omitting type in readonly declaration
• Confusing const and readonly syntax

3. What will be the output of the following C# code?

class Test {
    public readonly int Value;
    public Test(int val) {
        Value = val;
    }
}

class Program {
    static void Main() {
        var t = new Test(10);
        Console.WriteLine(t.Value);
    }
}

medium

A. 10

B. 0

C. Compilation error

D. Runtime error

Solution

1. Step 1: Understand readonly assignment in constructor

   The readonly field Value is assigned in the constructor with val, which is 10.

2. Step 2: Check output of Console.WriteLine

   The program prints the assigned value of Value, which is 10.

3. Final Answer:

   10 -> Option A

4. Quick Check:

   readonly set in constructor prints assigned value [OK]

Hint: readonly can be set once in constructor, then used [OK]

Common Mistakes:

• Assuming readonly defaults to 0 if assigned in constructor
• Thinking readonly cannot be assigned in constructor
• Expecting compilation or runtime errors

4. Identify the error in the following C# code:

class Sample {
    public const int Number;
    public Sample() {
        Number = 5;
    }
}

medium

A. Cannot assign a value to a const field outside declaration.

B. Const fields must be assigned in constructor, not declaration.

C. Const fields can be assigned multiple times.

D. No error, code is correct.

Solution

1. Step 1: Check const assignment rules

   const fields must be assigned a value when declared and cannot be assigned later.

2. Step 2: Analyze code assignment

   The code tries to assign Number = 5; inside the constructor, which is invalid for const.

3. Final Answer:

   Cannot assign a value to a const field outside declaration. -> Option A

4. Quick Check:

   const must be assigned only at declaration [OK]

Hint: const value fixed at declaration, not in constructor [OK]

Common Mistakes:

• Trying to assign const in constructor
• Confusing const with readonly assignment rules
• Assuming no error in code

5. You want to create a class that stores a fixed tax rate that never changes and a discount rate that can be set once when the object is created but never changed after. Which declarations are correct in C#?

hard

A. public double TaxRate = 0.15; public readonly double DiscountRate;

B. public readonly double TaxRate = 0.15; public const double DiscountRate;

C. public static double TaxRate = 0.15; public double DiscountRate;

D. public const double TaxRate = 0.15; public readonly double DiscountRate;

Solution

1. Step 1: Assign fixed tax rate with const

   The tax rate never changes, so const is appropriate for TaxRate.

2. Step 2: Assign discount rate once at object creation

   The discount rate can be set once when the object is created, so readonly is suitable for DiscountRate.

3. Step 3: Eliminate incorrect options

   public readonly double TaxRate = 0.15; public const double DiscountRate; swaps const and readonly incorrectly; public static double TaxRate = 0.15; public double DiscountRate; uses mutable fields; public double TaxRate = 0.15; public readonly double DiscountRate; uses non-const for tax rate.

4. Final Answer:

   public const double TaxRate = 0.15; public readonly double DiscountRate; -> Option D

5. Quick Check:

   const fixed forever, readonly set once at creation [OK]

Hint: Use const for fixed, readonly for one-time set [OK]

Common Mistakes:

• Using readonly for fixed values
• Using const for values set at runtime
• Not understanding when to use static