JavaScript Naming Conventions: Best Practices

Rules vs Conventions

Two different things get called “naming rules,” and separating them makes everything else clearer.

The rules are covered in detail in JavaScript Case Sensitivity. This guide is about the second column — the choices that make a codebase readable.

Why conventions are worth the effort

The Four Casing Styles

JavaScript has four conventional casing styles, and each one is tied to a specific kind of thing. Learning the mapping is most of the battle.

What about kebab-case?

kebab-case is a valid and common convention — in CSS, in HTML class names, and in file names. In JavaScript it is a syntax error, because the hyphen is the subtraction operator.

The full mapping

What to Name Each Kind of Value

Variables — a noun

A variable holds a value, so its name should be a noun that describes what the value means, not what it is.

Functions — a verb

A function does something, so its name should be a verb phrase. Reading it at the call site should describe the action.

// A verb phrase describes what the function does
function calculateTotal(items) { }
function fetchUser(id) { }
function renderCard(data) { }
function validateEmail(value) { }
function formatPrice(cents) { }
function parseQueryString(search) { }
function isWithinRange(value, min, max) { }

// Nouns as function names are a smell —
// they usually mean the function is doing
// too much or the name is not specific
function user(id) { }        // what about the user?
function total(items) { }    // total what?

Classes — a noun in PascalCase

// A class describes a kind of thing
class UserAccount { }
class ShoppingCart { }
class HttpClient { }
class ValidationError extends Error { }

// Methods inside a class still use camelCase
class UserAccount {
    constructor(name) {
        this.name = name;
        this.#createdAt = new Date();
    }

    #createdAt;   // private field

    getDisplayName() { }
    updateEmail(newEmail) { }
    isActive() { }
}

Constants — SCREAMING_SNAKE_CASE, but only when it is true

This is the rule people get wrong most often. SCREAMING_SNAKE_CASE is reserved for values that are known before the program runs — configuration, limits, magic numbers. A const holding a computed value is not one of those.

// True constants — SCREAMING_SNAKE_CASE
const MAX_RETRIES = 3;
const API_BASE_URL = 'https://api.example.com';
const DEFAULT_TIMEOUT_MS = 5000;
const TAX_RATE = 0.2;
const SUPPORTED_LOCALES = ['en', 'fr', 'de'];

// Module-level config objects often get this treatment too
const CONFIG = Object.freeze({
    retries: 3,
    timeout: 5000
});

// But a value computed from other values is camelCase,
// even at module level
const defaultTimeout = MAX_RETRIES * 1000;   // computed

The Prefix Patterns That Do the Heavy Lifting

A small set of prefixes carries a surprising amount of meaning. Learning them makes names self-documenting without any extra effort.

• Booleans that describe state. isReady, hasPermission, isLoading, hasError. The name reads as a question, which is exactly what an if statement asks.
• Booleans that describe capability or intent. canEdit, shouldRetry, canSubmit. Useful when the boolean is about what is allowed rather than what currently is.
• Event handlers and callbacks. handleClick is the function that does the work; onClick is the prop or option it is passed to. The distinction makes the role obvious.
• Accessors. getUser() reads a value; setUser() writes one. In classes, get and set are also real keywords for property accessors.
• Data retrieval. fetchUser() suggests a network request; loadConfig() suggests reading from disk or cache. The verb signals the cost.

Booleans should read as a question

// These read naturally inside an if statement
if (isLoading) { }
if (hasPermission) { }
if (canEdit) { }
if (shouldRetry) { }

// These do not — the reader has to work out
// what the boolean means
if (loading) { }
if (permission) { }
if (edit) { }
if (retry) { }

// And avoid negative names — a double negative is
// almost always harder to read
if (!isNotReady) { }    // confusing
if (isReady) { }        // clearer

// If the value is genuinely the absence of something,
// name it that way and use it that way
if (isMissing) { }      // fine — it reads as a question

Handlers vs callbacks

See the difference in real code

This example is built entirely with prefix conventions. Read the variable names and it should be clear what each one holds before you look at the code that produces it.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Prefix Conventions</title>
    <style>
        body {
            font-family: system-ui, sans-serif;
            padding: 28px;
            background: #f8fafc;
            margin: 0;
            color: #0f172a;
        }
        .panel {
            background: #fff;
            border: 1px solid #e2e8f0;
            border-radius: 14px;
            padding: 22px;
            max-width: 420px;
        }
        .status {
            display: flex;
            align-items: center;
            gap: 8px;
            font-size: 0.82rem;
            font-weight: 700;
            letter-spacing: 0.06em;
            text-transform: uppercase;
            margin-bottom: 14px;
        }
        .dot {
            width: 8px;
            height: 8px;
            border-radius: 50%;
        }
        .dot--on { background: #16a34a; box-shadow: 0 0 8px rgba(22,163,74,.5); }
        .dot--off { background: #cbd5e1; }
        .label { color: #64748b; }
        .btn {
            border: 0;
            border-radius: 10px;
            background: #0891b2;
            color: #fff;
            font: inherit;
            font-weight: 600;
            font-size: 0.88rem;
            padding: 10px 18px;
            cursor: pointer;
            margin-right: 8px;
        }
        .btn:hover { background: #0e7490; }
        .btn:disabled { background: #cbd5e1; cursor: not-allowed; }
    </style>
</head>
<body>

    <div class="panel">
        <div class="status">
            <span class="dot dot--off" id="dot"></span>
            <span id="label">Not running</span>
        </div>
        <button class="btn" id="toggle">Start</button>
    </div>

    <script>
        // Every name below signals its role through its prefix

        let isRunning = false;               // boolean — reads as a question
        let hasStartedOnce = false;          // boolean — also a question
        const MAX_TOGGLES = 5;               // true constant
        let toggleCount = 0;                 // computed value — camelCase

        const dotElement   = document.getElementById('dot');
        const labelElement = document.getElementById('label');
        const toggleButton = document.getElementById('toggle');

        function canToggle() {               // capability — can
            return toggleCount < MAX_TOGGLES;
        }

        function renderStatus() {            // verb — does something
            dotElement.className   = isRunning ? 'dot dot--on' : 'dot dot--off';
            labelElement.textContent = isRunning ? 'Running' : 'Not running';
            toggleButton.textContent = isRunning ? 'Stop' : 'Start';
            toggleButton.disabled    = !canToggle();
        }

        function handleToggle() {            // handler — handle
            if (!canToggle()) return;

            isRunning      = !isRunning;
            hasStartedOnce = true;
            toggleCount   += 1;

            renderStatus();
        }

        toggleButton.addEventListener('click', handleToggle);
        renderStatus();
    </script>

</body>
</html>

Notice how the names alone tell you the shape of the program. isRunning and hasStartedOnce are obviously booleans. canToggle() is obviously a capability check. handleToggle is obviously an event handler. Nothing here needs a comment to explain what it holds.

How Long Should a Name Be?

The right length depends on the scope. A name used across a whole module needs to carry its meaning on its own. A name used inside a two-line loop can afford to be short.

// Fine — the scope is two lines and the meaning is obvious
for (let i = 0; i < items.length; i++) { }

// Fine — conventional mathematical shorthand
function distance(x1, y1, x2, y2) { }

// Not fine — `u` is used across a whole module
export function u(id) { }               // what is u?

// Better
export function fetchUser(id) { }

// Fine — a short name inside a small callback
items.map(n => n * 2);

// Not fine — a short name for something important
const d = new Date();
const t = calculateTotal(cart);          // what is t?

// Better
const createdAt = new Date();
const orderTotal = calculateTotal(cart);

When short names are acceptable

• Loop indices. i, j, and k are universal.
• Coordinates and dimensions. x, y, w, h in geometry or graphics code.
• Array callbacks. n, item, el inside a map or forEach.
• Error catch variables. err or e is universally understood.
• Event variables. event or evt inside a handler.

Everywhere else, a short name costs more time to decode than it saved in typing.

Abbreviations: usually a mistake

Naming in Practice: Before and After

The clearest way to see the value of conventions is a refactor. Here is the same component written twice. Both versions work; only one is maintainable.

Before — vague and inconsistent

// What is `d`? What is `x`? What does `f` do?
function f(d) {
    const x = d.list;
    const t = x.length;

    if (t === 0) {
        return 'no data';
    }

    let s = 0;
    for (let i = 0; i < t; i++) {
        s += x[i].p;
    }

    return s;
}

const d = getData();
const r = f(d);
console.log(r);

// Inconsistent casing in the same file
const user_name = 'Ada';
const UserEmail = 'ada@example.com';
const MAX_ITEM_COUNT = 10;
const default_count = 5;

After — descriptive and consistent

// Every name says what it holds
function calculateOrderTotal(order) {
    const lineItems = order.lineItems;
    const itemCount = lineItems.length;

    if (itemCount === 0) {
        return 0;
    }

    let total = 0;
    for (let i = 0; i < itemCount; i++) {
        total += lineItems[i].price;
    }

    return total;
}

const currentOrder = fetchOrder();
const orderTotal = calculateOrderTotal(currentOrder);
console.log(orderTotal);

// Consistent casing throughout
const userName = 'Ada';
const userEmail = 'ada@example.com';
const MAX_ITEM_COUNT = 10;      // true constant
const defaultItemCount = 5;     // computed value

Common Naming Mistakes

Each of these makes a name actively harder to work with. They are the ones that come up most often in real code reviews.

1. Single letters outside a tiny scope

2. Names that repeat the type

3. Catch-all names: data, info, temp

4. Negative boolean names

5. Inconsistent casing in the same file

6. Names that lie

7. Names that differ by one character

8. Abbreviating past the point of clarity

9. Shadowing a built-in

10. Naming by position rather than role

Making It Stick: Tooling and Consistency

A convention that lives only in a document drifts. A convention enforced by a tool holds. The good news is that the tooling is easy to set up.

ESLint

// .eslintrc.json — enforce the common conventions

{
    "rules": {
        // Variables and functions must be camelCase
        "camelcase": ["error", { "properties": "always" }],

        // No shadowing built-ins or outer variables
        "no-shadow": "error",
        "no-shadow-restricted-names": "error",

        // No redeclaring — catches accidental duplicates
        "no-redeclare": "error",

        // Custom pattern rules for specific naming families
        "id-match": ["error", "^[a-z][a-zA-Z0-9]*$", {
            "properties": false,
            "onlyDeclarations": true
        }]
    }
}

TypeScript’s naming-convention rule

If you use TypeScript with the ESLint plugin, the @typescript-eslint/naming-convention rule lets you express the whole table in one place.

// eslint.config.js — the full convention as a rule

'@typescript-eslint/naming-convention': [
    'error',

    // Variables — camelCase, or SCREAMING_SNAKE_CASE for constants
    {
        selector: 'variable',
        format: ['camelCase', 'UPPER_CASE']
    },

    // Booleans must start with a recognised prefix
    {
        selector: 'variable',
        types: ['boolean'],
        format: ['camelCase'],
        prefix: ['is', 'has', 'can', 'should', 'did']
    },

    // Functions — camelCase
    {
        selector: 'function',
        format: ['camelCase']
    },

    // Classes, interfaces, and type aliases — PascalCase
    {
        selector: 'typeLike',
        format: ['PascalCase']
    },

    // Object properties may also be snake_case, for API payloads
    {
        selector: 'objectLiteralProperty',
        format: ['camelCase', 'snake_case']
    }
]

Prettier does not do this — and that is fine

Prettier formats whitespace, quotes, and line breaks. It does not rename anything, and it cannot enforce a casing convention. That is what ESLint is for. The two work together: Prettier handles layout, ESLint handles rules.

Best Practices

These habits cover nearly every naming decision you will face. When in doubt, start here.

Key Takeaways

• Naming conventions are style, not syntax — the language does not enforce them.
• camelCase for variables and functions, PascalCase for classes, SCREAMING_SNAKE_CASE for true constants.
• Hyphens are not valid in JavaScript identifiers — use camelCase instead.
• Prefix booleans with is, has, can, or should.
• Use verbs for functions and nouns for variables.
• Match the length of a name to the size of its scope.
• Use handle for the handler function and on for the prop it is passed to.
• Avoid Hungarian notation — the type is already in the value.
• Avoid catch-all names like data, info, and temp.
• A name that lies is worse than a name that is vague — rename when the value changes.
• Name by role, not by position — layouts change, roles do not.
• Enforce the convention with ESLint in CI so it survives past the first week.

What to Learn Next

Now that the naming conventions are clear, the next step is the language rules that sit underneath them. Read JavaScript Case Sensitivity for what the parser actually enforces, and JavaScript Strict Mode for the mode that catches several naming mistakes automatically.

From there, explore JavaScript Syntax Explained, JavaScript Statements and Expressions, and JavaScript Functions Explained. For the CSS side of the same subject, read CSS Naming Conventions.

If you are still connecting the pieces, read What Is JavaScript?, JavaScript Comments, and JavaScript vs TypeScript for the surrounding context.

Practice Challenge

The fastest way to internalize a convention is to apply it to code that was written badly. This exercise takes about twenty-five minutes.

1. Create index.html and app.js, and load the script with <script src="app.js" defer></script>.
2. Write a deliberately badly named function: short name, single-letter parameters, and a body full of data, temp, and x. Confirm it works.
3. Add a second function that returns a boolean but is named as a noun, such as status().
4. Add four variables in the same file using four different casing styles: user_name, userEmail, UserAge, and USER_CITY.
5. Add a const inside a function that holds a computed value and name it in SCREAMING_SNAKE_CASE.
6. Now refactor every name: rename the function to a verb phrase, its parameters to descriptive nouns, and the internal variables to meaningful names.
7. Rename the boolean function to start with is, has, or can.
8. Convert all four variables to camelCase, and change the computed constant to camelCase as well.
9. Add a genuine constant at the top of the file with SCREAMING_SNAKE_CASE — something like MAX_ITEMS.
10. Add an event listener and name the handler with a handle prefix.
11. Now install ESLint in the project and enable the camelcase, no-shadow, and no-redeclare rules. Run it and see whether your refactored file passes.
12. Finally, deliberately rename one variable to differ from its use site by a single capital letter. Run ESLint and confirm it catches the undeclared reference.

If you complete those steps, you have written code that violates every major convention, refactored it into something readable, added a genuine constant alongside a computed one, and configured a linter to keep the rules in place. That sequence — write badly, refactor, enforce — is the whole practice of naming conventions. The refactor is the part that teaches you what the rules are for.