# Creating a Holistics Style Guide

**URL:** <https://community.holistics.io/t/creating-a-holistics-style-guide/687>\
**Category:** Ask the Community\
**Created:** [January 24, 2022, 1:36am UTC](https://community.holistics.io/t/creating-a-holistics-style-guide/687 "2022-01-24T01:36:07Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![david-ri](https://community.holistics.io/user_avatar/community.holistics.io/david-ri/32/543_2.png) [@david-ri](https://community.holistics.io/u/david-ri)\
**Post date:** [January 24, 2022, 1:36am UTC](https://community.holistics.io/t/creating-a-holistics-style-guide/687/1 "2022-01-24T01:36:07Z")

</div>

I’m looking to create a Style Guide for Holistics, to compliment our SQL and dbt style guides. This will set out best practice / policies / schemas etc to follow when working with Holistics (AML in particular)

Has anybody already done anything similar they’d be willing to share as a starting point?

-or-

What are people’s recommendations for including?

eg, we follow a structure per project

- `Sources` (1:1 with source tables - only basic changes / additional to these models)
- `Models` (our main models folder, and must always reference a Source model or other existing Models - never directly reference a table)
- `Datasets`

But I’d like to cover syntax, permissions / groups best practice etc

---

<div class="post-metadata">

**Author:** ![hapham](https://community.holistics.io/user_avatar/community.holistics.io/hapham/32/108_2.png) [@hapham](https://community.holistics.io/u/hapham)\
**Post date:** [January 28, 2022, 7:26am UTC](https://community.holistics.io/t/creating-a-holistics-style-guide/687/2 "2022-01-28T07:26:38Z")

</div>

Hi David, this is Ha from Holistics’s internal data team.

This question is interesting - we have not really looked into a Holistics Style Guide yet. Internally we also use dbt, and we have a dbt folder structure, model naming, field naming guide for Dimensions & Measures… Those things are often mirrored into our Holistics AML project.

How we are structuring our internal project:

```auto
.
|-- data_source
| |-- datasets
| | |-- name_by_team_or_usage
| |-- models
| | |-- name_by_source_applications
| | |-- name_by_usage
| | |-- ...

```

Notes:

- `data_source`: Models and datasets from **different data sources** should be separated in different parent folders.
- `datasets` folder contains `.dataset.aml` files. It can be grouped by their usage, or the teams that it mainly serves
- `models` folder contains `.model.aml` files. It is best to mirror the dbt project structure here.

For Models & Datasets naming,

- **Naming:** AML models can also follow the dbt model naming guide.
  - File names and model names can reuse the name defined in the dbt project.
  - `use_lower_case_and_dash`

- **Labeling:** Since the label is what the end-user see, it should be descriptive and easy to understand
  - Avoid too much abbreviation
  - Remove prefixes and suffixes (like dim, facts…)
  - `Use Upper Case And No Dash`

There is also a field (Holistics Dimension & Measure) naming guide. If this is what you are looking for, we will try to publish a public version of it