Hello, friends! I am glad to present you the second part of my thoughts on naming in JavaScript. If you missed the first one, you can catch up here:
"Naming Conventions in JavaScript (Classes, Components, Events, APIs)" (first part)
In this post we will cover the following:
camelCase
vs.UPPER_SNAKE_CASE
.Boolean variables (
is
,has
).Arrays (plural), objects (context).
Constants, DOM-elements (
buttonElement
).
Good variable naming enhances code clarity, maintainability, and reduces errors.
📌 1. Use camelCase
In JavaScript, camelCase is the standard for variables:
// 👍 Good
let userName = "John";
let totalPrice = 100;
// 👎 Bad
let user_name = "John"; // snake_case (non-JS standard)
let TotalPrice = 100; // PascalCase (for classes)
📌 2. Names should be descriptive
Avoid names that are too short or generic:
// 👍 Good
let customerEmail = "user@example.com";
let maxRetryAttempts = 3;
// 👎 Bad
let em = "user@example.com"; // What is `em`?
let mra = 3; // Unclear
📌 3. Booleans: Start with is
, has
, can
Such variables should reflect the state or presence of something:
// 👍 Good
let isLoggedIn = true;
let hasPermission = false;
// 👎 Bad
let loggedIn = true; // Not obviously boolean
📌 4. Arrays/Collections: Use Plural Names
This helps distinguish an array from an individual element:
// 👍 Good
let users = ["John", "Anna"];
// 👎 Bad
let userList = ["John", "Anna"]; // Redundant suffix
📌 5. Objects: Reflect Purpose
The name should reflect what the object contains:
// 👍 Good
let userProfile = { name: "John" };
// 👎 Bad
let data = { name: "John" }; // Too generic
📌 6. Constants: UPPER_SNAKE_CASE and camelCase
If you explicitly set the value for the content, then use UPPER_SNAKE_CASE
:
// 👍 Good
const MAX_USERS = 100;
// 👎 Bad
const maxUsers = 100; // Not obviously constant
If the value of the content is added dynamically, as a result of code execution, then use camelCase
:
// 👍 Good
const BIRTHDAY_USER = '18.04.1982';
const ageUser = someCode(BIRTHDAY_USER); // The value of the constant is assigned dynamically
// 👎 Bad
const BIRTHDAY_USER = '18.04.1982';
const AGE_USER = someCode(BIRTHDAY_USER);
📌 7. Numeric variables must specify units of measurement (if required)
// 👍 Good
let timeoutInMs = 2000;
let maxItemsCount = 10;
// 👎 Bad
let timeout = 2000; // Milliseconds? Seconds?
let maxItems = 10; // Without context
📌 8. Destructuring with clear names)
// 👍 Good
const { name: userName, age: userAge } = user;
// 👎 Bad
const { name, age } = user; // If `name` is already used above
But there are exceptions to every rule, so there are the following specific cases in JavaScript as well.
Specific cases:
📌 1. Counters and indices (i
, j
, k
)
It is permissible to use short names in cycles:
for (let i = 0; i < 10; i++) { ... }
📌 2. Intermediate values (temp, result)
If the variable is temporary, you can use temp or result:
let temp = calculateSomething();
let result = processData(data);
📌 3. DOM-elements (element
, button
, input
)
Add a prefix to indicate that it is a DOM element:
// 👍 Good
const submitButton = document.querySelector("#submit");
const emailInput = document.querySelector("#email");
// 👎 Bad
const submit = document.querySelector("#submit"); // Not obvious
Conclusion: how to name variables correctly?
Descriptive names (
userName
,maxRetryAttempts
).camelCase
for variables,UPPER_SNAKE_CASE
for constants.Boolean variables start with
is
,has
,can
.Name arrays in the plural (
users
,products
).Avoid generic names (
data
,value
,item
).
Examples of good naming:
const MAX_RETRIES = 3;
let currentUser = { name: "John" };
let isModalOpen = false;
const fetchUserData = async () => { ... };
const products = [{ id: 1 }, { id: 2 }];
If you have doubts about the name, imagine another developer seeing it. Will they understand what this variable is for?
Read more:
"Naming Conventions in JavaScript (Classes, Components, Events, APIs)" (first part)
"How to Name Functions in JavaScript: A Practical Guide" (third part)
Top comments (2)
this is extremely impressive and honestly lines up exactly with how i try to handle my own naming. you ever run into a case where the 'right' name just feels off for some reason
Yes, there was a case where I insisted on using 'PaymentService', but the codebase was using 'PaymentsProcessor'. I realized consistency was more important than my 'perfect' naming. Now I see such situations as examples that code is a collective language, not a personal manifesto 😊