Choose names that clearly convey a variable’s, function’s, or module’s purpose, type, and visibility, and keep that meaning consistent everywhere it’s used. Follow established architectural naming patterns (e.g., name a use-case class NotesService rather than NotesUseCase if the codebase follows Controller-Service-Repository conventions). When requiring a module-specific identifier (such as a deprecate namespace), use the actual package name instead of an unrelated or component-specific string. Never repurpose the same property or variable name to mean different things in different contexts (e.g., don’t reuse _router for both the public router proxy and an internal field with different semantics) — pick a distinct, descriptive name instead. For private or internal-only state, mark it clearly, e.g. with a leading underscore (_router, _parsedQs), so its intent is unambiguous. When dealing with function parameters, avoid reassigning the parameter itself (which can silently mutate arguments and trigger deopts); instead declare a new local variable with a related but distinct name, such as:
function createApplication(options) {
var opts = options || {};
...
}
Similarly, prefer a generic name like val over obj when a variable may hold any type, so the name doesn’t mislead about the kind of value it stores. Consistent, intention-revealing names reduce confusion, prevent accidental misuse, and make code easier to review and maintain.