Naming & Formatting Conventions — Follow consistent naming and formatting conventions (camelCase)

Historical Context & Motivation

From the earliest days of computing, programmers realized that code is read far more often than it is written. When teams of developers work on the same project, inconsistent naming turns collaboration into a frustrating puzzle. Naming conventions — agreed-upon rules for how you name variables, functions, and other identifiers — emerged as a solution. In JavaScript specifically, the convention known as camelCase became the dominant standard, shaping how millions of developers write code every day.

The central question this lesson addresses is straightforward but critical: How should you name things in JavaScript so that your code is clear, consistent, and easy for others (and your future self) to understand? The answer lies in mastering a small set of conventions that the entire JavaScript community follows.

Core Principles of Naming & Formatting

Good naming is not about following arbitrary rules — it is about communicating intent. When you read let x = 5; versus let studentAge = 5;, the second version tells you what the data means. The following principles guide every naming decision you will make in JavaScript.

Visual Guide to Naming Styles

The diagram below shows how the same multi-word phrase — "get user age" — gets formatted under each major naming convention used in programming. Notice how camelCase visually creates "humps" like a camel's back, which is where the name comes from.

Notice that each convention has a specific purpose. The style you choose immediately tells a reader what kind of identifier they are looking at. A variable called shoppingCart is clearly an instance or a plain value, while ShoppingCart signals a class that you would instantiate with new. This visual distinction makes code self-documenting.

How camelCase Works — Rules & Patterns

The mechanics of camelCase are simple, but the details matter. Understanding the precise rules helps you apply them automatically in every line of code you write.

Rule 1: Start with a Lowercase Letter

The first word of a camelCase identifier is always entirely lowercase. This distinguishes it from PascalCase, where the first letter is capitalized. For example, totalScore starts with a lowercase t, not an uppercase T.

Rule 2: Capitalize the First Letter of Each Subsequent Word

Every word after the first begins with a capital letter, and the remaining letters are lowercase. The phrase "number of students" becomes numberOfStudents. No spaces, hyphens, or underscores separate the words — the capital letters serve as the visual word boundaries.

Rule 3: Choose Meaningful Words

Conventions dictate the format, but you still choose the words. A well-named variable answers the question "what does this hold?" without requiring extra comments. Compare let d = new Date(); with let currentDate = new Date(); — the second version needs no explanation.

Common Patterns for Different Identifier Types

Formatting Conventions Beyond Names

Naming is only half the story. Formatting conventions govern how your code is visually structured: indentation, spacing, brace placement, and line length. Consistent formatting makes code scannable at a glance, just like how consistent paragraph formatting makes an essay easier to read.

Key Formatting Rules in JavaScript

• Indentation: Use 2 spaces (most common in JavaScript) or 4 spaces — but pick one and use it everywhere. Never mix tabs and spaces.
• Semicolons: Always include semicolons at the end of statements. While JavaScript has automatic semicolon insertion, relying on it can cause subtle bugs.
• Braces: Place the opening brace on the same line as the statement (not on a new line). Always use braces with if, for, and while — even for single-line bodies.
• Spacing: Add spaces around operators (x + y, not x+y), after commas, and after keywords like if and for.
• Line length: Keep lines under 80–100 characters. Break long expressions across multiple lines for readability.

Worked Example: Refactoring Bad Names

Let's walk through refactoring a piece of poorly named and formatted code into clean, conventional JavaScript. Imagine a classmate hands you this code and asks you to figure out what it does.

Naming Conventions Across Languages

Different programming languages prefer different naming conventions. Understanding these differences helps you switch between languages without carrying incorrect habits. The table below shows the preferred convention for variables and functions in several popular languages.

Linters & Formatters — Automating Conventions

As your projects grow, manually enforcing conventions becomes impractical. This is where linters and formatters come in. These automated tools check your code for convention violations (linting) and automatically fix formatting issues (formatting), just like a spell-checker and grammar-checker work together in a word processor.

In professional development teams, ESLint and Prettier are typically used together. ESLint handles naming and logic rules, while Prettier handles visual formatting. Many code editors, like VS Code, integrate both tools so that your code is automatically checked and formatted every time you save a file. As you move into more advanced courses or begin contributing to open-source projects, you will encounter style guides — comprehensive documents (like the Airbnb JavaScript Style Guide or Google's JavaScript Style Guide) that define every convention a team follows. These style guides are then enforced through linter configurations.

Practice Problems

Lesson Summary