Naming Conventions

Code is read far more often than it’s written. A good name makes the next line easier to understand. A bad one forces you to stop, trace backwards, and reconstruct what the author meant. That friction compounds across an entire codebase.

The goal: code that reads like prose

Before getting into rules, here’s the standard to aim for.

This is hard to read…

FUNCTION calc(a, b):
    RETURN a * b

But this reads like a sentence!

FUNCTION calculateRectangleArea(width, height):
    RETURN width * height

Same logic. No extra comments needed in the second version — the names do the explaining. That’s the goal.

What a name cannot be

Before choosing a good name, it helps to know what’s off-limits. These rules apply in virtually every programming language:

• Cannot start with a number — 2fast is invalid; fast2 is fine
• Cannot contain spaces — user age is invalid; that’s why conventions like user_age or userAge exist
• Cannot use special characters — symbols like +, -, @, ! are reserved for operations, not names (some languages allow _ and $ as exceptions)
• Cannot be a reserved keyword — words the language already uses (if, return, class, for) cannot be repurposed as names

Violating any of these will cause a syntax error before your program even runs.

Naming styles (case conventions)

Since spaces are forbidden, multi-word names need a different way to separate words. Several conventions exist, and different languages have settled on different ones.

snake_case — words separated by underscores, all lowercase

user_age
calculate_future_value
is_logged_in

Common in: Python, PHP, Ruby, SQL

camelCase — first word lowercase, each subsequent word starts with a capital

userAge
calculateFutureValue
isLoggedIn

Common in: JavaScript, Java, Swift, Go (for variables and functions)

PascalCase (also called UpperCamelCase) — every word starts with a capital, including the first

UserAge
CalculateFutureValue
InvoiceProcessor

Common in: class names in most languages; C# for everything; React components

UPPER_SNAKE_CASE — all capitals, words separated by underscores

MAX_RETRIES
DEFAULT_TIMEOUT
PI

Common in: constants across most languages

kebab-case — words separated by hyphens, all lowercase

user-age
background-color
main-container

Common in: CSS, HTML attributes, URLs — not valid in most programming languages because - is interpreted as subtraction

The convention you use depends on the language and what you’re naming. Here’s a quick reference:

Language	Variables & Functions	Classes	Constants
Python	snake_case	PascalCase	UPPER_SNAKE_CASE
JavaScript	camelCase	PascalCase	UPPER_SNAKE_CASE
Java	camelCase	PascalCase	UPPER_SNAKE_CASE
C#	camelCase	PascalCase	PascalCase
CSS/HTML	kebab-case	—	—

The most important thing isn’t which convention you use — it’s that you pick one and stay consistent throughout a project.

Variables: name the thing, not the type

A variable name should describe what it holds, not what type it is.

# Bad
s = "Alice"
n = 42
lst = [1, 2, 3]

# Good
username = "Alice"
age = 42
scores = [1, 2, 3]

Avoid single-letter names except in two cases: loop counters (i, j) and coordinates (x, y). These are conventions everyone recognises.

Also avoid filler words that add length without adding meaning:

# Bad
dataList = []
valueVar = 0
tempString = "hello"

# Good
results = []
count = 0
greeting = "hello"

If you find yourself writing _list, _var, or _data as a suffix, ask what the thing actually contains and name it that instead.

Booleans: name them as yes/no questions

A boolean is always true or false. Its name should read like a question with an obvious answer.

# Bad
active = true
check = false
userStatus = true

# Good
isActive = true
hasPermission = false
isLoggedIn = true

The is, has, can, was prefixes signal immediately that the value is a boolean. When you read if isActive it lands cleanly. if active is ambiguous — active what?

Functions: name what they do, not how

A function name should describe the action it performs. Use a verb.

# Bad
FUNCTION data(userId): ...
FUNCTION process(items): ...

# Good
FUNCTION fetchUser(userId): ...
FUNCTION filterExpiredItems(items): ...

data and process say nothing — every function deals with data and processes something. fetchUser and filterExpiredItems tell you what will happen when you call them.

If you’re struggling to name a function, it sometimes means the function is doing too much. A function that’s hard to name is often a function that should be two functions.

Classes: name what they represent

Classes represent things — objects, concepts, entities. Use a noun. Use PascalCase regardless of language.

# Bad
CLASS handleUser: ...
CLASS dataProcessor: ...

# Good
CLASS User: ...
CLASS InvoiceProcessor: ...

The name should describe what an instance of the class is, not what the class does. User is a thing. handleUser is a task.

A quick test

Before finalising a name, run it through this:

1. Can I tell what this holds (or does) without reading the implementation?
2. Would someone unfamiliar with the code understand it?
3. Is it as short as it can be while still being clear?

If the answer to any of those is no, rename it. It takes ten seconds and saves minutes of confusion later.

What just happened?

Naming is the cheapest form of documentation. A well-named variable, function, or class is a comment you never have to write and never have to keep up to date.

The rules here split into two layers: hard restrictions (no spaces, no leading numbers, no special characters, no reserved words) that the language enforces, and soft conventions (snake_case, camelCase, PascalCase) that your language community has agreed on. Both matter — one stops your code from running, the other stops your code from being readable.

In the next unit you’ll look at functions — how to write them so they do one thing well, stay readable, and don’t surprise the person calling them.