Best practices on naming convention

Good naming reminds you what, not how.

This guide gives you clean, straightforward naming rules that keep your code readable and scalable. No fluff. Just practical conventions you can rely on.

Naming Convention for Functions

A function name must express the action and the intention. Most functions should start with a verb.

If the function returns a boolean, start with prefixes like is, can, or has.

❌ Bad patterns:

• user (what does it do?)
• doUpdate (what is updated?)
• processData (vague)
• checkEmail (check what exactly? validity? existence?)

✅ Good patterns:

• getUserById
• calculateTotal
• updateProfile
• isEmailValid

Your function name must tell the reader what the function returns or does.

Avoid generic words like handle, manage, process, thing, stuff

Avoid abbreviations unless the meaning is universal: URL, HTML, ID

Short names are not better. Clear beats short.

Naming Convention for Variables

Use clear, descriptive nouns. Your variable should tell you exactly what it holds.

❌ Bad patterns:

• x (too short, meaningless)
• dataThing (vague, does not explain the data)
• val (ambiguous, unclear what value it represents)
• tmp123 (temporary and non-descriptive)
• cardSelectedThing (confusing and overly long)

✅ Good patterns:

• user
• totalPrice
• isLoading
• tempCard
• selectedCard

Keep acronyms uppercase only when they are standard (URL, ID, HTML).

Naming Convention for Lists

Use plural nouns. Do not include the type in the name. Your code already knows it is an array.

❌ Bad patterns:

• usersArray (redundant, type is obvious)
• cardList (unnecessary "List")
• arrOfProducts (redundant and verbose)
• messageCollection (too generic)

✅ Good patterns:

• users
• cards
• products
• messages

Naming Convention for Classes

Use PascalCase. Classes represent entities or models, so use nouns or noun phrases.

❌ Bad patterns:

• usercontroller (incorrect casing, unclear)
• order_manager (snake_case, inconsistent)
• ProcessClass (vague, does not describe what it processes)
• ThingHandler (generic and non-descriptive)

✅ Good patterns:

• UserService
• CardManager
• Order
• AuthController

Classes should not use verbs unless the class itself represents an action object, which is rare.

Naming Convention for Constants

Use uppercase with underscores when the value is truly constant.

❌ Bad patterns:

• maxRetry (not uppercase)
• TimeOutConst (mixed casing, unclear)
• defaultLang_123 (includes numbers, unclear purpose)

✅ Good patterns:

• MAX_RETRY_COUNT
• API_TIMEOUT
• DEFAULT_LANGUAGE

Naming Convention for Files and Modules

Stay consistent with your project’s ecosystem.

• JavaScript or TypeScript files: camelCase or kebab-case, but pick one.
• React components: PascalCase.

❌ Bad patterns:

• helpers.js (too generic)
• stuff.js (vague, unclear purpose)
• Utils2.ts (unclear, numbered versioning)

✅ Good patterns:

• format-date.ts
• use-auth.ts
• UserCard.tsx

Naming Convention for Event Handlers

Event handler names should clearly communicate the action being performed and the context in which it occurs. This makes it easier to understand what each handler does and which data it affects.

❌ Bad patterns:

• doClick (vague, does not specify what was clicked)
• clickIt (unclear and non-descriptive)
• submitHandler (generic, lacks context)
• doSubmit (does not explain what is being submitted)
• buttonClick (too generic, does not indicate which button)
• handleBtnClick (unclear which element triggers the handler)

✅ Good patterns:

• handlePaymentCardClick(cardId) – clearly shows it handles a click on a payment card and accepts the card ID
• handleUserProfileSubmit(userId, formData) – specifies it handles submission of a user profile form, including relevant data
• onPaymentSubmit – clearly indicates a payment submit event

---

Naming Convention for React Components

React component names should use PascalCase and clearly describe their role, purpose, and content. Avoid vague or generic names.

❌ Bad patterns:

• CardsComp (unclear, generic)
• CardsContainer (does not specify content or purpose)
• FormThing (vague, does not indicate the form’s role)
• ProfileContainer (generic, unclear purpose)
• Btn (non-descriptive, unclear function)
• Clicker (too generic, unclear action)
• MyButton (non-descriptive)
• ResultsComponent (generic, does not indicate what results)
• ResultBox (unclear, generic)

✅ Good patterns:

• PaymentCardList – displays a list of payment cards
• UserProfileForm – handles user profile input
• PrimarySubmitButton – clear button role with primary action
• KeywordSearchResults – shows search results for a specific keyword