Naming (Variables)

This article covers naming conventions for variables in Model Reef.

Good variable names make it easier to:

• Read and review your model.

• Search and filter variables.

• Use autocomplete reliably in formulas and drivers.

• Collaborate with other users.

You will learn:

• What makes a good variable name.

• Recommended naming patterns.

• How to handle variants, overrides and scenarios.

• Common mistakes to avoid.

1

What a variable name should convey

A variable name should tell you, at a glance:

• What the variable represents.

• Which part of the business it relates to.

• How it behaves, if relevant (for example count vs rate vs amount).

Examples:

• Revenue - Subscriptions - UK

• COGS - Hardware - Europe

• Staff - Engineering - Headcount

• Marketing - Paid Search - Spend

• Capex - New Store Rollout

If you can answer "what is this?" and "where is this?" from the name alone, it is probably a good name.

2

Recommended naming pattern

A simple, robust pattern is:

[Category or type] - [Subject] - [Qualifier]

Where:

• Category or type gives the high level context, for example Revenue, COGS, Opex, Staff, Capex.

• Subject describes the product, activity or cost driver, for example Subscriptions, Hardware, Support Team.

• Qualifier adds a geography, channel, unit type or other useful dimension, for example UK, Online, Headcount.

Examples:

• Revenue - Subscriptions - Online

• Revenue - Services - Enterprise

• Opex - Marketing - Paid Social

• Staff - Sales - Headcount

• Capex - Data Centre - Phase 1

You do not need all three parts for every variable, but keeping to a consistent pattern pays off when models become large.

3

Align names with categories and branches

Variable names should be consistent with their:

• Category and subcategory.

• Branch (entity, division, store, project).

For example, if a variable lives in branch Store Sydney and category Revenue - Retail, a good name could be:

• Revenue - Retail - Sydney

• Or Revenue - Store Sales - Sydney

This way, you can often understand the branch and category context directly from the name when scanning lists or using search.

4

Naming variants and overrides

Sometimes you have multiple variables that are closely related, for example:

• Base cost vs scenario override.

• Original budget vs updated forecast.

• Old product vs new product.

To keep them clear:

• Include a suffix describing the role, for example Base, Override, Scenario B, Legacy, New.

• Use tags as well as names if there are many similar variables.

Examples:

• Revenue - Subscriptions - UK - Base

• Revenue - Subscriptions - UK - Scenario B

• Opex - Marketing - Brand - Legacy

• Opex - Marketing - Brand - New Strategy

Avoid names that differ only by a numeric suffix with no meaning, for example Revenue 1, Revenue 2, as these become confusing quickly.

5

Abbreviations and readability

Short names are convenient, but they should still be understandable. Guidelines:

• Use standard abbreviations where they are widely recognised, for example GP, EBITDA, FX, COGS.

• Avoid internal shorthand that only one person understands.

• Do not rely on codes alone (for example ACC_1001) unless you also include a plain language description in the name.

Remember that variable names appear in:

• Formula autocomplete.

• Drill down views from reports and charts.

• Data Library listings.

Readable names save time every time you or someone else uses the model.

6

Renaming variables safely

You can rename variables without breaking the model.

Behind the scenes, references are tracked by internal IDs rather than by the display name, so:

• Formulas that reference the variable continue to work after renaming.

• Reports and dashboards that include the variable update to show the new name.

• Data Library entries linked to the variable remain connected.

This means you can safely improve names over time as the model matures.

7

Common naming mistakes to avoid

Try to avoid:

• Overly generic names, for example Revenue, Cost, Staff, when there are many such items.

• Names that do not match the branch or category, for example Revenue - UK inside an Australia only branch.

• Hard coded dates in names, for example Revenue 2024, unless the variable really is specific to that period.

• Long sentences as names. Use concise but descriptive labels instead.

If you are unsure, choose clarity. It is easier to shorten a descriptive name later than to decode an ambiguous one during a review.

---

Related articles

• Loan Book Growth Forecasting

• Build a Working Capital Model

• Categories

• Formula Editor Layout