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:
getUserByIdcalculateTotalupdateProfileisEmailValid
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:
usertotalPriceisLoadingtempCardselectedCard
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:
userscardsproductsmessages
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:
UserServiceCardManagerOrderAuthController
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_COUNTAPI_TIMEOUTDEFAULT_LANGUAGE
Naming Convention for Files and Modules
Stay consistent with your project’s ecosystem.
- JavaScript or TypeScript files:
camelCaseorkebab-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.tsuse-auth.tsUserCard.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 IDhandleUserProfileSubmit(userId, formData)– specifies it handles submission of a user profile form, including relevant dataonPaymentSubmit– clearly indicates a payment submit event
Naming Convention for React Props
1. 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
onClickcallback"
2. State Transition Names
They describe a resulting state after logic has run.
This resulting state can be either an action or a state transition
-
Action
These describe commands or intent or intrusction.
Usually start with:
verb+nounand 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-
State Transition
These describe notifications or outcomes after logic has completed.
Usually use this format:
on+nounif availableon+past-tense verbif not
Think as of:
“This already happened.”
# auth
onAuthSuccess
onAuthError
# payment
onPaymentAuthorized
onPaymentDeclined
onPaymentCaptured
# form & validation libraries
onValidationPassed
onValidationFailed
onSubmitSucceeded
onSubmitFailed
# dropzone
onDropAccepted
onFileAccepted
onFileRejectedRule
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.
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 cardsUserProfileForm– handles user profile inputPrimarySubmitButton– clear button role with primary actionKeywordSearchResults– shows search results for a specific keyword