DEV Community

Sabin Sim
Sabin Sim

Posted on

02. C# (Naming variables)

0) Goal of This Lesson

Learn how to name variables in a way humans can read easily,
and build the habit of safely renaming variables instead of getting stuck with bad names.

This is not about theory.
It’s about writing code, running it, and feeling why naming matters.


1) Why Variable Names Matter

The compiler doesn’t care whether your variable is called a, x, or temp.

People do.

  • Your future self (even one week later)
  • Teammates
  • You, when debugging at 2 a.m.

The fastest way to make code understandable is good naming.
This is where Clean Code actually starts.


2) Why You Can’t Name Variables Arbitrarily

2-1) Reserved Keywords (C# already uses these words)

Examples: int, class, string

❌ This will not compile:

int int = 5;
Enter fullscreen mode Exit fullscreen mode

Because C# already uses int to mean “integer type”.
The compiler gets confused.


2-2) Allowed Characters in Variable Names

Allowed:

  • Letters
  • Numbers
  • Underscore (_)

Not allowed:

  • Most special characters
  • Starting with a number

❌ Invalid examples:

int 1count = 0;   // cannot start with a number
int count-1 = 0;  // '-' is not allowed
Enter fullscreen mode Exit fullscreen mode

2-3) Case Sensitivity (Uppercase ≠ Lowercase)

int count = 1;
int Count = 2; // different variables
Enter fullscreen mode Exit fullscreen mode

C# is case-sensitive.


3) What If You Really Want to Use a Reserved Keyword?

You technically can, by prefixing it with @.

string @class = "Business";
Enter fullscreen mode Exit fullscreen mode

This is called keyword escaping.

✅ But in real projects, this is usually clearer:

string ticketClass = "Business";
Enter fullscreen mode Exit fullscreen mode

More readable, less confusing.


4) The Standard Naming Style in C#: camelCase

Rules are simple:

  • Start with a lowercase letter
  • Capitalize each new word

✅ Examples:

string userInput;
int itemCount;
string ticketClass;
Enter fullscreen mode Exit fullscreen mode

This is the default for local variables and parameters in C#.


5) Bad Names vs Good Names (This Is the Core Skill)

❌ Bad names (no intent):

string a;
string b;
string c;
Enter fullscreen mode Exit fullscreen mode

✅ Good names (intent is obvious):

int year;
int month;
int day;
Enter fullscreen mode Exit fullscreen mode

This difference directly affects:

  • Debugging speed
  • Maintenance cost
  • Mental load

6) Run This Code and Feel the Difference

The code below demonstrates:

  1. Why meaningful names matter
  2. How to avoid reserved keywords
  3. Naming in a simple TODO-app context

✅ Fully runnable example:

using System;

class Program
{
    static void Main()
    {
        // TODO app menu
        Console.WriteLine("S - Show items");
        Console.WriteLine("A - Add item");
        Console.WriteLine("R - Remove item");
        Console.WriteLine("E - Exit");

        // Bad example: string a;  -> unclear
        // Good example:
        string userChoice = Console.ReadLine();

        Console.WriteLine("You selected: " + userChoice);

        // Reserved keyword example
        // string class = "Business"; // ❌ compile error
        string ticketClass = "Business"; // ✅ preferred
        Console.WriteLine("Ticket class: " + ticketClass);

        // Keyword escape (not recommended for everyday code)
        string @class = "Economy";
        Console.WriteLine("@class variable value: " + @class);

        // Intent-revealing variable names
        int year = 2026;
        int month = 1;
        int day = 29;
        string formattedDate = $"{year}/{month}/{day}";
        Console.WriteLine("Formatted date: " + formattedDate);
    }
}
Enter fullscreen mode Exit fullscreen mode

What you should notice when running it

  • The flow is easy to read without comments
  • userChoice explains itself
  • ticketClass is clearer than @class
  • Date construction reads like a sentence

7) Renaming Variables Safely (Real-World Habit)

The most important habit is this:

Don’t aim for perfect names on the first try.
Rename safely when understanding improves.

Modern IDEs make this trivial.

Rename refactoring:

  • Updates all usages
  • Avoids broken references
  • Much safer than manual search & replace

This is how clean code is actually maintained.


8) 30-Second Self-Check

If you can answer these, you’re done:

  1. Why is string a; a bad variable name?
  2. Why is ticketClass preferred over @class?
  3. What should you do when a variable name no longer feels right?

Top comments (0)