Naming Conventions: Variables, Functions, and Classes

Table of Contents

• Why Naming Is Hard
• Use Clear Names
• Avoid Ambiguous Abbreviations
• Name Variables by Meaning
• Name Functions by Action
• Name Booleans as Questions
• Name Classes by Responsibility
• Keep API Names Honest
• Conclusion

Why Naming Is Hard

Naming looks easy because it only requires typing a word. In practice, it is one of the hardest parts of programming.

A name shapes how another developer understands the code. If the name is vague, the reader has to inspect more context. If the name is misleading, the reader may build the wrong mental model entirely.

Good naming reduces cognitive load. It makes code easier to read before comments, documentation, or meetings are needed.

Use Clear Names

Prefer names that explain what the value represents.

Avoid:

$j = 12;
$stt = 'open';

Prefer:

$itemCount = 12;
$orderStatus = 'open';

The goal is not to make every name long. The goal is to make the meaning obvious.

Avoid Ambiguous Abbreviations

Abbreviations are useful only when everyone understands them. Common terms like id, url, api, and html are fine. Random shortcuts like usr, prd, cfg, or calcVal usually make code harder to read.

Instead of:

const usr = getUser();
const prodCnt = products.length;

Use:

const user = getUser();
const productCount = products.length;

Readable code saves time every time the file is reopened.

Name Variables by Meaning

Variables should describe the data they hold:

const monthlyRevenue = 12000;
const activeUsers = users.filter(user => user.isActive);
const shippingAddress = order.shippingAddress;

When there are multiple similar values, be specific:

const totalOrders = orders.length;
const paidOrders = orders.filter(order => order.isPaid).length;

Specific names help prevent accidental misuse.

Name Functions by Action

Functions should usually start with a verb because they do something:

calculateTotalPrice()
sendResetPasswordEmail()
validateUserInput()
createInvoice()

Avoid vague names:

handle()
process()
doThing()
run()

Those names force readers to open the function body to understand what happens.

Name Booleans as Questions

Boolean names should read like true-or-false statements:

const isActive = true;
const hasPermission = false;
const canEditPost = true;
const shouldRetry = false;

Avoid names that hide the boolean nature:

const status = true;
const permission = false;

Clear boolean naming makes conditions easier to scan:

if (user.isActive && user.canEditPost) {
  showEditor();
}

Name Classes by Responsibility

Classes should represent a clear concept or responsibility:

class InvoiceGenerator {}
class UserRepository {}
class PaymentGateway {}
class OrderValidator {}

Be careful with classes named:

class Manager {}
class Helper {}
class Processor {}
class Utility {}

Those names are often signs that the class responsibility is unclear.

Keep API Names Honest

API names should match what the endpoint actually does.

Avoid mixing action names, wrong HTTP methods, and surprising behavior:

POST /getUser

If the endpoint fetches a user, use:

GET /users/{id}

If it updates a user, use:

PATCH /users/{id}

Honest naming matters outside the codebase too. API consumers rely on names to understand behavior quickly.

Conclusion

Good names are small pieces of documentation embedded directly in code. They help teammates, future maintainers, and your future self.

When in doubt, choose clarity over cleverness. A boring but accurate name is usually better than a short name that needs explanation.