There's an old joke in programming: there are only two hard things in computer science — cache invalidation and naming things. We'll leave caches for another day. Today is about naming, because it's the cheapest, fastest way to make your code dramatically better — no new frameworks required.

Why names are your biggest readability lever

Here's a truth that changes how you write code: code is read far more often than it is written — many developers put the ratio at ten to one. You write a line once, but you (and your teammates, and future-you at 2 a.m. hunting a bug) will read it again and again.

Names are where that reading happens. A good name answers questions before anyone asks them; a bad name forces every reader to stop and decode. Multiply that pause by every reader, every visit, for the life of the code — that's the cost of a lazy name.

Six rules for better names

  • Reveal intent. A name should say what the thing is for. d tells you nothing; daysSinceLastVisit tells you everything. If a name needs a comment to explain it, the name isn't done yet.
  • Avoid mental mapping. Abbreviations like appTmp or pRec2 force readers to hold a secret decoder ring in their head. Spell it out: pendingAppointment, previousPatientRecord. Your editor autocompletes — long names cost nothing to type.
  • Make booleans read as questions. isOpen, hasExpired, canEdit. Then your conditions read like sentences: if (clinic.IsOpen) needs no explanation, while if (clinic.Status2) needs an investigation.
  • Include units. Is delay in seconds or milliseconds? Is price in rupees or cents? delayMs and priceInRupees settle it forever — and prevent the kind of unit mix-up bugs that are famously expensive.
  • Keep one vocabulary. Don't mix fetchPatient, getDoctor, and retrieveClinic in the same codebase for the same idea. Pick one word — say, get — and use it everywhere. Consistency makes code guessable.
  • Match name length to scope. A loop variable that lives for three lines can be p. A field used across a whole class deserves maxAppointmentsPerDay. The farther a name travels from its definition, the more it must explain itself.

Tip: Never fix a bad name with find-and-replace. Every editor has a rename refactoring (F2 in VS Code) that updates the definition and every usage safely. Because renaming is this cheap, there's no excuse to live with a name that lies.

A before-and-after makeover

Let's prove that names alone carry meaning. Here's a method from an imaginary clinic app. First, the "before" — the logic is fine, but reading it feels like solving a puzzle:

public List<Appointment> Get(List<Appointment> l, int d)
{
    var r = new List<Appointment>();
    foreach (var a in l)
    {
        if ((DateTime.Now - a.Date).Days <= d)
        {
            r.Add(a);
        }
    }
    return r;
}

What is d? What ends up in r? You have to trace the logic to find out. Now the same code with only the names changed — not a single piece of logic touched:

public List<Appointment> GetRecentAppointments(
    List<Appointment> appointments, int maxAgeInDays)
{
    var recentAppointments = new List<Appointment>();
    foreach (var appointment in appointments)
    {
        var ageInDays = (DateTime.Now - appointment.Date).Days;
        if (ageInDays <= maxAgeInDays)
        {
            recentAppointments.Add(appointment);
        }
    }
    return recentAppointments;
}

Same behavior, but now the method explains itself: it returns appointments no older than a given number of days. No comments, no documentation — the names are the documentation.

Naming in the AI era

Here's a modern twist: good names don't just help humans anymore. AI coding assistants predict what you want from the context you give them — and names are most of that context. Type CalculateInvoiceTotal and your assistant will likely suggest sensible invoice math; type DoStuff2 and it's guessing as blindly as your coworkers.

Note: Don't fear long names. numberOfMissedAppointments beats numMissAppt every single time. Clarity wins over brevity — screens are wide, and autocomplete does the typing.

Your next step is simple: open something you wrote recently and rename three things to reveal their intent. That's it — you're now writing cleaner code than most beginners. If you're picking up the language, start with why C# is a great first language, and when you're ready to save those beautifully renamed files properly, learn Git basics: commits, branches, and why. Happy renaming!