Search code examples
refactoringrenamenaming-conventionsnaming

Should I rename internal references to a feature name if it's name in the UI has changed?


During development, an internal name is given to a particular feature. That name is then used in function and variable names. Later, when the UI and Documentation are finalized, a different public-facing name is assigned to that feature. Should variable names be renamed too to correspond to the new public name?

On one side, the public-facing name may change frequently and so it is unpractical to rename internal references all the time. On the other hand, it can create confusion in meetings and among new team members if a single feature has different names (should there be a spreadsheet that maps the public and private names?).

Is there an industry standard for this?


Solution

  • The concept of an "ubiquitous language" discusses how external and internal names should be consistent.

    To quote this great article:

    Ubiquitous Language is the term that Eric Evans uses in “Domain-Driven Design – Tackling Complexity in the Heart of Software” in order to build a language shared by the team, developers, domain experts, and other participants.

    Using consistent names makes it easier for all parties to understand concepts in the product and code.