> For the complete documentation index, see [llms.txt](https://help.modelreef.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.modelreef.io/syntax/variables-syntax/naming-and-autocomplete.md).

# Naming & Autocomplete

This article explains **Naming and Autocomplete** for variables in Model Reef.

You will learn:

* How to name variables so they are easy to find and reuse.
* How autocomplete helps you reference variables in formulas and searches.
* How naming conventions support clarity and governance.

Names are the primary way humans navigate and understand the model.

{% stepper %}
{% step %}

### Where names are used

Variable names appear in:

* The Variable Editor header.
* Lists of variables for each branch.
* The Data Library.
* Category and branch summaries.
* Formula sidebars and autocomplete suggestions.
* Dashboards, charts and reports.

A clear name makes a variable easier to reuse correctly.
{% endstep %}

{% step %}

### Editing names

You can edit a variable's name in the **Variable Editor** header.

When you rename a variable:

* All references to it in formulas and charts update automatically.
* It appears under the new name everywhere in the interface.

Renaming does not change the variable's type, category or branch.
{% endstep %}

{% step %}

### Autocomplete behaviour

When you type in fields that accept variable references, such as formulas or search boxes:

* Model Reef offers autocomplete suggestions based on what you have typed so far.
* Suggestions may include variable names, driver names and sometimes categories.
* Selecting a suggestion inserts a correctly formatted reference to that item.

Autocomplete reduces typos and ensures that references remain linked even if names are later changed.
{% endstep %}

{% step %}

### Naming conventions

Good naming conventions often include:

* A short prefix indicating type or section, for example `Rev -`, `COGS -`, `Opex -`, `Staff -`.
* A descriptive subject, such as the product, channel or cost area.
* Optional branch or region codes when needed.

Examples:

* `Rev - Online - AU`
* `COGS - Materials`
* `Opex - Marketing - Paid Ads`
* `Staff - Engineers`

Agree conventions across the team to avoid duplication and confusion.
{% endstep %}

{% step %}

### Searching by name

You can search for variables by name in:

* The Variable list.
* The Data Library.
* Sometimes in formula sidebars or pickers.

Consistent naming makes it much easier to:

* Find variables for review.
* Reuse existing logic instead of creating near duplicates.
* Navigate large models quickly.
  {% endstep %}

{% step %}

### Documentation in names versus notes

Names should be short and descriptive, but not full explanations.

Use:

* Names for concise identification.
* Notes in the Variable Editor for detailed descriptions, assumptions and data sources.

This balance keeps the interface tidy while preserving all necessary context.
{% endstep %}
{% endstepper %}

## Related articles

* [Auto-Validation Rules](/syntax/how-input-fields-work/auto-validation-rules.md)
* [Branch Assignment](/syntax/variables-syntax/branch-assignment.md)
* [Naming (Branches)](/help/building-your-model/naming-branches.md)
* [Build a Multi Division Model](/how-tos/core-modelling/build-a-multi-division-model.md)