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.

LinkIconNaming 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.

LinkIconNaming 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).

LinkIconNaming 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

LinkIconNaming 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.

LinkIconNaming 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

LinkIconNaming 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

LinkIconNaming 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

LinkIconNaming Convention for React Props

LinkIcon1. Event Names

They are named after the event itself:

  • click → onClick
  • change → onChange
  • submit → onSubmit
  • focus → onFocus
  • blur → onBlur

Notice these events are nouns and they describe something that happened. The preffix on means that you are subscribing to the event.

For example, onClick means:

"When a click event occurs, run onClick callback"

LinkIcon2. State Transition Names

They describe a resulting state after logic has run.

This resulting state can be either an action or a state transition

  1. Action

    These describe commands or intent or intrusction.

    Usually start with: verb + noun and are often called by the consumer (a child component).

    Think of it as:

    "Do this now"

openModal
closeModal
submitForm
saveChanges
startUpload
cancelUpload
retryRequest
refreshData
selectItem
deleteAccount
  1. State Transition

    These describe notifications or outcomes after logic has completed.

    Usually use this format:

    • on + noun if available
    • on + past-tense verb if not

    Think as of:

    “This already happened.”

# auth
onAuthSuccess
onAuthError
 
# payment
onPaymentAuthorized
onPaymentDeclined
onPaymentCaptured
 
# form & validation libraries
onValidationPassed
onValidationFailed
onSubmitSucceeded
onSubmitFailed
 
# dropzone
onDropAccepted
onFileAccepted
onFileRejected

LinkIconRule

This is the rule I usually follow to decide if use action or state transaition names.

If the parent tells the child to do something → action. If the child informs the parent something happened → state transition.

LinkIconNaming 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