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;
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
2-3) Case Sensitivity (Uppercase ≠ Lowercase)
int count = 1;
int Count = 2; // different variables
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";
This is called keyword escaping.
✅ But in real projects, this is usually clearer:
string ticketClass = "Business";
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;
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;
✅ Good names (intent is obvious):
int year;
int month;
int day;
This difference directly affects:
- Debugging speed
- Maintenance cost
- Mental load
6) Run This Code and Feel the Difference
The code below demonstrates:
- Why meaningful names matter
- How to avoid reserved keywords
- 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);
}
}
What you should notice when running it
- The flow is easy to read without comments
-
userChoiceexplains itself -
ticketClassis 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:
- Why is
string a;a bad variable name? - Why is
ticketClasspreferred over@class? - What should you do when a variable name no longer feels right?
Top comments (0)