Semantic and consistent naming

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:

• Variable names should match their actual semantic role, not an earlier/narrower intent. For example, if a parameter can hold any value (not just an object), name it val rather than obj throughout its usage.
• When referencing the module/package itself (e.g., in deprecate() calls), use the actual npm package name rather than a submodule or internal name, so messages are meaningful to consumers.
• Follow established architectural naming patterns (e.g., Controller-Service-Repository) so classes and parameters are immediately recognizable by their role, such as naming a use-case/service class NotesService instead of a generic NotesUseCase when the project follows that convention.
• Clearly distinguish internal/private members from public API by using a leading underscore (e.g., _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.