DEV Community: Jarryd

C# Basics - What are the types of access modifiers in C#?

Jarryd — Tue, 14 Oct 2025 10:11:25 +0000

What Are the Types of Access Modifiers in C#?

Often, as junior C# developers, we write code all day that works, but we see words like private, public, internal, or protected on our classes, structs, and records. These are called access modifiers — but do we really know what they mean and when to use them?

Hopefully, this blog post will help you understand C# access modifiers better.

1. Public

Public members can be accessed by any type from any assembly.

Code Example – Same Assembly:

namespace AccessModifiers;

public class TestClass
{
    public string PublicField = "public";
}

public class Program
{
    static void Main(string[] args)
    {
        var testClassObject = new TestClass();
        Console.WriteLine($"Accessing public: {testClassObject.PublicField}");
        Console.ReadKey();
    }
}

Code Example – Another Assembly:

using AccessModifiers;

namespace AccessModifiersAnotherAssembly;

public class Program
{
    static void Main(string[] args)
    {
        var testClassObject = new TestClass();
        Console.WriteLine($"Accessing public: {testClassObject.PublicField}");
        Console.ReadKey();
    }
}

2. Internal

Internal members can be accessed by any other type within the same assembly in which they are defined. They cannot be accessed from outside that assembly.

Code Example:

namespace AccessModifiers;

public class TestClass
{
    public string PublicField = "public";
    internal string InternalField = "internal";
    protected string ProtectedField = "protected";
}

public class Program
{
    static void Main(string[] args)
    {
        var testClassObject = new TestClass();
        Console.WriteLine($"Accessing public: {testClassObject.PublicField}");
        Console.WriteLine($"Accessing internal: {testClassObject.InternalField}");
        Console.ReadKey();
    }
}

Code snippet – Another Assembly (unable to access the internal field):

3. Protected

Protected members can only be used by types that derive from the base class — in this case, TestClass.

They can also be accessed from another assembly if the derived class exists in that assembly.

Code Example:

using AccessModifiers;

namespace AccessModifiersAnotherAssembly;

public class Program
{
    static void Main(string[] args)
    {
        var testClassObject = new TestClass();
        Console.WriteLine($"Accessing public: {testClassObject.PublicField}");
        // Console.WriteLine($"Accessing protected: {testClassObject.ProtectedField}"); // Not allowed
        Console.ReadKey();
    }
}

public class ChildOfTestClassAnotherAssembly : TestClass
{
    public ChildOfTestClassAnotherAssembly()
    {
        Console.WriteLine(base.ProtectedField); // Allowed - derived class
    }
}

4. Private

The private modifier restricts access to members within the same class only. It cannot be accessed from any other class.

Code Example:

public class TestClass
{
    public string PublicField = "public";
    internal string InternalField = "internal";
    protected string ProtectedField = "protected";
    protected internal string ProtectedInternalField = "protected internal";
    private protected string PrivateProtectedField = "private protected";
    private string PrivateField = "private";
}

5. Protected Internal

Within the same assembly, protected internal behaves like internal, meaning it can be accessed from any class in that assembly.

In another assembly, it behaves like protected, meaning it’s only accessible from a derived class.

Code Example – Assembly 1:

namespace AccessModifiers;

public class TestClass
{
    public string PublicField = "public";
    internal string InternalField = "internal";
    protected string ProtectedField = "protected";
    protected internal string ProtectedInternalField = "protected internal";
}

public class ChildOfTestClass : TestClass
{
    public ChildOfTestClass()
    {
        Console.WriteLine(base.ProtectedField);
        Console.WriteLine(base.ProtectedInternalField);
    }
}

public class Program
{
    static void Main(string[] args)
    {
        var testClassObject = new TestClass();
        var testClassObject2 = new ChildOfTestClass();
        Console.WriteLine($"Accessing public: {testClassObject.PublicField}");
        Console.WriteLine($"Accessing internal: {testClassObject.InternalField}");
        Console.WriteLine($"Accessing protected internal: {testClassObject.ProtectedInternalField}");
        Console.ReadKey();
    }
}

Code Example – Assembly 2:

using AccessModifiers;

namespace AccessModifiersAnotherAssembly;

public class Program
{
    static void Main(string[] args)
    {
        var testClassObject = new TestClass();
        Console.WriteLine($"Accessing public: {testClassObject.PublicField}");
        Console.ReadKey();
    }
}

public class ChildOfTestClassAnotherAssembly : TestClass
{
    public ChildOfTestClassAnotherAssembly()
    {
        Console.WriteLine(base.ProtectedField);
        Console.WriteLine(base.ProtectedInternalField); // Works only because of inheritance
    }
}

6. Private Protected

Within the same assembly, private protected behaves like protected — meaning it can be accessed from derived classes within the same assembly only.

Outside of the assembly, it is not accessible at all.

Code Example:

namespace AccessModifiers;

public class TestClass
{
    public string PublicField = "public";
    internal string InternalField = "internal";
    protected string ProtectedField = "protected";
    protected internal string ProtectedInternalField = "protected internal";
    private protected string PrivateProtectedField = "private protected";
}

public class ChildOfTestClass : TestClass
{
    public ChildOfTestClass()
    {
        Console.WriteLine(base.ProtectedField);
        Console.WriteLine(base.ProtectedInternalField);
        Console.WriteLine(base.PrivateProtectedField); // Works - same assembly
    }
}

public class Program
{
    static void Main(string[] args)
    {
        var testClassObject = new TestClass();
        var testClassObject2 = new ChildOfTestClass();
        Console.WriteLine($"Accessing public: {testClassObject.PublicField}");
        Console.WriteLine($"Accessing internal: {testClassObject.InternalField}");
        Console.WriteLine($"Accessing protected internal: {testClassObject.ProtectedInternalField}");
        // Console.WriteLine(testClassObject.PrivateProtectedField); // Not accessible
        Console.ReadKey();
    }
}

All the examples above use classes, but access modifiers work the same way for classes, structs, and records.

However, not all access modifiers are supported by structs, since structs do not support inheritance.

DotNet basics: What is Spaghetti Code?

Jarryd — Tue, 01 Jul 2025 11:05:53 +0000

Spaghetti code is a term developers use to describe code that’s messy, tangled, and hard to follow. It often grows without structure and becomes a pain to work with—especially when you're trying to add new features or fix bugs.

What causes spaghetti code?

Large classes and methods
Multiple responsibilities in one class
Using the goto keyword
Bad naming
Magic numbers
Code repetition

An example

public class OrderProcessor
{
    public void ProcessOrder()
    {
        Console.WriteLine("Enter product ID:");
        int productId = int.Parse(Console.ReadLine());

        Console.WriteLine("Enter quantity:");
        int quantity = int.Parse(Console.ReadLine());

        double price = 0;
        if (productId == 1)
            price = 10.99;
        else if (productId == 2)
            price = 15.49;
        else if (productId == 3)
            price = 5.25;

        double total = price * quantity;

        Console.WriteLine("Do you want express shipping? (y/n)");
        string shipping = Console.ReadLine();

        if (shipping == "y")
        {
            total += 5.0;
        }

        Console.WriteLine("Order Summary:");
        Console.WriteLine("Product ID: " + productId);
        Console.WriteLine("Quantity: " + quantity);
        Console.WriteLine("Total Price: $" + total);

        Console.WriteLine("Saving order...");
        Console.WriteLine("Order saved.");
    }
}

What’s wrong here?

One class is doing everything
Magic numbers everywhere
No reuse or structure
Not easy to test or maintain

A cleaner, more structured version

public class ProductService
{
    public double GetPrice(int productId)
    {
        return productId switch
        {
            1 => 10.99,
            2 => 15.49,
            3 => 5.25,
            _ => throw new ArgumentException("Invalid product ID")
        };
    }
}

public class Order
{
    public int ProductId { get; set; }
    public int Quantity { get; set; }
    public bool ExpressShipping { get; set; }

    public double CalculateTotal(double pricePerItem)
    {
        double total = pricePerItem * Quantity;
        if (ExpressShipping)
        {
            total += 5.0;
        }
        return total;
    }
}

public class OrderUI
{
    private readonly ProductService _productService = new();

    public void Run()
    {
        var order = new Order();

        Console.WriteLine("Enter product ID:");
        order.ProductId = int.Parse(Console.ReadLine());

        Console.WriteLine("Enter quantity:");
        order.Quantity = int.Parse(Console.ReadLine());

        Console.WriteLine("Do you want express shipping? (y/n)");
        order.ExpressShipping = Console.ReadLine()?.ToLower() == "y";

        double price = _productService.GetPrice(order.ProductId);
        double total = order.CalculateTotal(price);

        Console.WriteLine($"
Order Summary:");
        Console.WriteLine($"Product ID: {order.ProductId}");
        Console.WriteLine($"Quantity: {order.Quantity}");
        Console.WriteLine($"Total Price: ${total}");

        Console.WriteLine("Saving order...");
        Console.WriteLine("Order saved.");
    }
}

Why this is better

Each class handles one job
It’s easier to follow and test
We can reuse the logic later

Other code smells

Ravioli code – Each class is clean, but there are so many tiny parts that the overall structure gets confusing.
Lasagna code – Too many tightly coupled layers. Changing one breaks everything else.

Question - How do you avoid writing messy, tangled, and hard to follow code?

DotNet Basics: What are the three main types of errors in C#? 🐞

Jarryd — Wed, 04 Jun 2025 11:50:34 +0000

🤔 Question - What was the most annoying programming error you've ever faced? How did you deal with it?

Since we're talking about errors, I thought today would be perfect to cover the fundamentals that every developer encounters.

The reality:

As much as I’d love to believe I can write perfect code without ever seeing an error message…Errors are something every developer deals with whether you're just starting out or have been coding for years.

Over time, I’ve come across all kinds of errors while building applications. Some were quick fixes. Others had me questioning everything.

So, to all the beginners out there navigating the chaos of red squiggly lines and cryptic messages, let’s break down the different types of errors you’re likely to face.

In programming, there are three main types of errors, we’re going to break them down using C#.

1️⃣ Compilation Errors

These happen when your code breaks the rules of the language, your compiler usually catches them before your app even runs.

Example - the compiler throws an error because we forgot a semicolon at the end of the Console.WriteLine("Hello World!") statement or the fact the main method should be spelt "Main"

🔧 Simple Fix:

2️⃣ Runtime Errors:

These show up while your program is running and can cause it to crash or behave in unexpected ways (think: dividing by zero or trying to access something that doesn't exist).

Example - We try to access the first element of an empty list

Error Message:

3️⃣ Logical Errors:

These are the sneaky ones. Your program runs just fine… but gives you the wrong output because something in your logic is off.

Example - Let’s say we want to join three words—First Name, Middle Name, and Last Name—and print them out as a full name.

We could write the following C# code:

The code runs without any issues, but the output looks like this:

Why? Because there's a small logic error. On line 12, we forgot to include a space in the separator:

return string.Join("", words);

to fix this we would change this to:

return string.Join(" ", words);

which gives us the output

💡 Key Takeaway

Every error is a learning opportunity. The more you encounter and solve them, the better you become at spotting patterns and debugging efficiently. Don't let errors discourage you.

What's the most memorable programming error you've encountered?
How is AI transforming the way you debug code?

DotNet Basics: What is the difference between C# and .NET?

Jarryd — Sun, 23 Feb 2025 11:00:00 +0000

A common question, especially for those new to the field, is the difference between C# and .NET.

C# is a programming language, providing the syntax and tools for writing code.

.NET is a framework, a collection of tools and libraries that provide essential services for running applications.

I like to think of it like this: 💭

C# is the Car 🚗 — The tool to accomplish your goals .
NET is the road 🛣️ —it provides the infrastructure, rules, and support that allow your application (the car) to operate effectively.

When we talk about .NET, we're really talking about two main things that work together to make your applications run smoothly:

The Common Language Runtime (CLR): Imagine the CLR as the engine that powers your .NET applications. It takes the code you write and translates it into instructions that the computer can understand. The CLR also handles important tasks like memory management (keeping track of what the computer is storing) and error handling (dealing with problems that might occur).
Standard Libraries: .NET provides a huge toolbox of pre-written code called standard libraries. These libraries contain ready-made solutions for common programming tasks. Think of them as building blocks that you can use to quickly create your applications. Here are some examples:
- System.Collections: For managing collections of data, like lists and dictionaries.
- System.IO: For working with files and folders.
- System.Net: For creating applications that communicate over a network.
- System.Text: For working with text and strings.
- System.Threading: For creating applications that can do multiple things at the same time."

.NET VS .NET Framework? 💻

A common point of confusion arises when distinguishing between .NET and the .NET Framework.

Originally released in 2002, the .NET Framework served as the initial platform for building applications primarily on Windows.

In 2016, Microsoft introduced .NET Core, a successor designed for cross-platform development, enabling applications to run on Windows, macOS, and Linux.

With the release of .NET 5.0 in 2020, Microsoft unified .NET Core with the .NET Framework and Xamarin under a single umbrella, now simply referred to as .NET.

Question - Looking back at your .NET learning journey, what concepts or technologies initially caused you the most confusion?

DotNet Basics: What is the Common Intermediate Language?

Jarryd — Mon, 10 Feb 2025 07:58:33 +0000

The Common Intermediate Language (CIL), sometimes referred to as Intermediate Language (IL), is the low-level programming language that all .NET-compatible languages—such as C#, VB.NET, and F#—are compiled into.

How Does CIL Work?
Compilation Time: When you write code in a .NET language like C#, the compiler does not directly generate machine code. Instead, it compiles the source code into CIL.

Runtime Execution:
At runtime, the Just-In-Time (JIT) compiler translates the CIL into binary (machine) code, which is then executed by the CPU.
All .NET languages compile to the same intermediate language, this enables cross-language interoperability—for example, a C# class can inherit from an F# class seamlessly.

Viewing CIL Code
To see the CIL code generated from your .NET project, you can use the IL Disassembler (ildasm.exe) tool, which is included with the .NET SDK.

Steps to View CIL Code:

Locate the compiled DLL or EXE:
After building your project, navigate to bin/Debug/netX.X/ (replace X.X with your .NET version).
Open ILDASM:
Run ildasm.exe from the Developer Command Prompt.
Drag and drop your DLL or EXE into ILDASM.
This will show you the CIL code that your source code was compiled into.

What is the Just-In-Time (JIT) Compiler?
The JIT Compiler is a feature of the Common Language Runtime (CLR) that translates CIL into machine code at runtime, just before the code is executed. This allows .NET applications to run efficiently on different hardware architectures while still maintaining performance.

Why is CIL Important?

Interoperability: Different .NET languages can work together since they compile to the same CIL.
Portability: CIL code is platform-independent until JIT compiles it to machine code.
Security & Optimization: The CLR can apply runtime optimizations based on the executing environment.

Final Thoughts:
Understanding CIL and how the JIT compiler works gives you deeper insights into .NET's inner workings. Whether you’re debugging, optimizing performance, or experimenting with cross-language compatibility, knowing how .NET compiles and executes code can make you a better developer.