Choose identifiers that accurately reflect what they represent and stay consistent with established project or architectural conventions. Avoid names that mislead about scope, purpose, or type.
Specifically:
val rather than obj throughout its usage.deprecate() calls), use the actual npm package name rather than a submodule or internal name, so messages are meaningful to consumers.NotesService instead of a generic NotesUseCase when the project follows that convention._router) or another consistent convention, and never reuse the same name for a public property and an internal one with different semantics (e.g., don’t have both a public app.router method and an internal _router property that serve different purposes under confusingly similar names).Applying these rules keeps code self-documenting, reduces ambiguity about visibility/intent, and prevents subtle bugs or confusion caused by names that no longer match their actual usage.