Skip to content

Commit d6c766d

Browse files
marcosqlbimarcosqlbi
committed
Added DAX format and naming conventions guidelines
1 parent a1260d0 commit d6c766d

3 files changed

Lines changed: 180 additions & 0 deletions

File tree

‎_mydocs/dax-style/dax-format.md‎

Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
---
2+
layout: page
3+
title: DAX Format
4+
published: true
5+
order: /
6+
---
7+
8+
Rules for formatting DAX code, to improve readability and maintainability. There are the rules implemented by [DAX Formatter](https://www.daxformatter.com).
9+
10+
- Never use shortened [CALCULATE](https://dax.guide/calculate) syntax
11+
- It means don’t use `[measure](filter)` but `CALCULATE( [measure], filter )` instead
12+
- Always put a space before parenthesis `(` and `)`
13+
- Always put a space before any operand and operator in an expression
14+
- If an expression has to be split in more rows, the operator is the first character in a new line
15+
- A function call in an expression split in more rows has to be always in a new row, preceded by an operator
16+
- Never put a space between table name and column name
17+
- Only use single quotes for table name if it is required
18+
- Meaning, omit single quotes if table name has no spaces or special characters
19+
- Use `ThisTable` instead of `'ThisTable'`
20+
- USe `'This Table'` instead of `This Table`
21+
- Use `'ThisTable42'` instead of `ThisTable42`
22+
- Never use table names for measure references
23+
- Always use table names for column references
24+
- Always put a space before an argument, if it is in the same line
25+
- Write a function inline only if it has a single argument that is not a function call
26+
- Always put arguments on a new line if the function call has 2 or more arguments
27+
- The "long" format of DAX Formatter can include more arguments in the same line
28+
- The "short" format of DAX Formatter strictly follow the one-argument-per-line rule
29+
- We use the "short" format for educational content, the "long" format in real-world scenarios
30+
- If the function is written on more lines:
31+
- The opening parenthesis `(` is on the same line of the function call
32+
- The arguments are in new lines, indented 4 spaces from the beginning of the function call
33+
- The closing parenthesis is aligned with the beginning of the function call
34+
- The comma separating two arguments is on the same line of the previous argument (no spaces before)

‎_mydocs/dax-style/dax-naming-conventions.md‎

Lines changed: 136 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,136 @@
1+
---
2+
layout: page
3+
title: DAX naming conventions
4+
published: true
5+
order: /
6+
---
7+
8+
The naming conventions for DAX coding in reality involve many objects of the semantic model and reflect the need of exposing clear names to the user and to keep the code readable and maintainable. The following sections describe the conventions for the main DAX and semantic model objects.
9+
10+
# Golden rules for all objects
11+
- All names should be written using names that are clear for the business users and understandable in the reports.
12+
- Avoid using abbreviations or acronyms unless they are widely recognized and understood by the business users.
13+
14+
# Tables
15+
- Do not use any technical prefix, like `dim` or `fact`.
16+
- Use a single noun when possible for a table name.
17+
- When more words are part of a table name, separate them by using a space if the table may be visible to the users, like `Coupons Orders`.
18+
- You might use PascalCase (e.g., `PricingConfiguration`) if the table name is designed to be invisible to the user.
19+
- Use singular nouns for qualitative business entities (e.g., `Customer`, `Product`, `Sales Region`).
20+
- Use uncountable or plural nouns for quantitative business entities (e.g., `Sales`, `Inventory`, `Revenue`, `Movements`).
21+
22+
# Columns
23+
- Do not use any technical prefix, like `date` or `string`.
24+
- Use a single noun when possible for a column name.
25+
- When more words are part of a column name, separate them by using a space if the table may be visible to the users, like `Coupons Orders`.
26+
- You might use PascalCase (e.g., `PricingConfiguration`) if the column name is designed to be invisible to the user.
27+
28+
# Measures
29+
- The measure name should clearly describe its result.
30+
- When more words are part of a measure name, separate them by using a space if the measure may be visible to the users, like `Sales Amount`.
31+
- You might use PascalCase (e.g., `SalesAmount`) if the measure name is designed to be invisible to the user.
32+
- Consider common acronyms that are widely recognized and understood by the business users, like `ROI` or `YOY`.
33+
- Use time intelligence acronyms like `YTD`, `QTD`, `MTD`, `PY`, `LY` as a suffix, like `Sales Amount YTD` or `Sales Amount PY`. A common list of time intelligence acronyms is provided below:
34+
| Acronym | Meaning |
35+
|---------|---------|
36+
| YTD | Year-to-date |
37+
| QTD | Quarter-to-date |
38+
| MTD | Month-to-date |
39+
| MAT | Moving annual total |
40+
| PY | Previous year |
41+
| PQ | Previous quarter |
42+
| PM | Previous month |
43+
| PYC | Previous year complete |
44+
| PQC | Previous quarter complete |
45+
| PMC | Previous month complete |
46+
| PP | Previous period (automatically selects year, quarter, or month) |
47+
| PYMAT | Previous year moving annual total |
48+
| YOY | Year-over-year |
49+
| QOQ | Quarter-over-quarter |
50+
| MOM | Month-over-month |
51+
| MATG | Moving annual total growth |
52+
| POP | Period-over-period (automatically selects year, quarter, or month) |
53+
| PYTD | Previous year-to-date |
54+
| PQTD | Previous quarter-to-date |
55+
| PMTD | Previous month-to-date |
56+
| YOYTD | Year-over-year-to-date |
57+
| QOQTD | Quarter-over-quarter-to-date |
58+
| MOMTD | Month-over-month-to-date |
59+
| YTDOPY | Year- to-date-over-previous-year |
60+
| QTDOPQ | Quarter-to-date-over-previous-quarter |
61+
| MTDOPM | Month-to-date-over-previous-month |
62+
63+
# Variables
64+
- Variable names should be written in PascalCase.
65+
- Define a last variable named Result to hold the final result of the measure or expression.
66+
- This allows to quickly restore the expression logic when editing it for debugging purposes.
67+
- You may use a prefix like `_` (underscore) for variable names.
68+
- While this was required to avoid possible name conflicts in the past, it is no longer necessary.
69+
- However, it can still be useful to visually distinguish variables from other objects in the code.
70+
71+
# User-defined functions
72+
73+
## Function names
74+
- Function names should be written in PascalCase.
75+
- The dot character (.) is permitted within function names and is recommended for delineating categories.
76+
- This serves as an effective analogue to namespaces commonly found in many programming languages.
77+
- **Model-dependent** functions should include a prefix (like `Local.`) to avoid conflicts with future DAX function names
78+
- However, the prefix may be further specialized if needed.
79+
- For complex models with numerous model-dependent functions warranting categorization, `Local.` should serve as the initial segment of the prefix.
80+
- Examples:
81+
- `GetCustomerDiscount`
82+
- `Model.GetCustomerDiscount` if you prefer to make it more explicit that the function is model-dependent.
83+
- `Model.Checkout.GetCustomerDiscount` where Checkout is a prefix to group similar or related functions.
84+
- **Do not use** `Checkout.GetCustomerDiscount` because it would appear as a model-independent function.
85+
86+
- **Model-independent** functions must begin with a prefix indicating at least the containing library.
87+
- Examples:
88+
- `Math.SumTwoNumbers` where Math is the library name.
89+
- `Math.Common.SumTwoNumbers` where Math is the library name and Common is a prefix to group similar or related functions.
90+
- `CompanyName.Math.SumTwoNumbers` where CompanyName is a prefix for all the libraries of the company.
91+
- **Do not use** `SumTwoNumbers` because it would appear as a model-dependent function.
92+
- You cannot use `Dax` as a noun part of the function name, as Microsoft reserves it.
93+
- You should not use `DaxLib` as an initial prefix for a function name, as it is reserved for general-purpose libraries maintained by the [DAX Lib](https://daxlib.org) community.
94+
95+
## Parameters
96+
- Use [camelCase](https://en.wikipedia.org/wiki/Camel_case) for parameter names.
97+
- Include a suffix indicating the parameter type for `EXPR` parameters:
98+
- `Column` for a column reference.
99+
- `Table` for a table reference.
100+
- `Measure` for a measure reference.
101+
- `Expr` for a DAX expression that is not necessarily a single column reference, table reference, or measure reference.
102+
- `Calendar` for a calendar reference, which cannot be an expression.
103+
104+
As a result, `YearlySales` is interpreted as a variable, whereas `yearlySales` indicates a parameter. Adhering to these conventions significantly improves code readability, particularly when working with complex functions.
105+
106+
Examples of `EXPR` parameter names are: `lookupTable`, `listPriceColumn`, `amountMeasure`, `metricExpr`.
107+
108+
## Comments
109+
110+
Comments describing functions are typically introduced with a triple forward slash (///) directly before the function declaration. This notation serves to document the function’s purpose. For example, the following function converts the temperature from Celsius to Fahrenheit:
111+
```
112+
/// Convert from Celsius(°C) to Fahrenheit(°F)
113+
FUNCTION CelsiusToFahrenheit = ( temperature: DOUBLE ) =>
114+
( temperature * ( 9 / 5 ) ) + 32
115+
```
116+
117+
**NOTE**: *There is no official proposal for documenting function parameters and return values. The following information is subject to change in future versions of Power BI Desktop and Tabular Editor. We will update this page as soon as a standard will be defined.*
118+
119+
Here is a possible technique inspired by the JSDoc standard (https://en.wikipedia.org/wiki/JSDoc) that can be used in September 2025 version of Power BI Desktop and shows the parameters in the function description:
120+
```
121+
/// Convert from Celsius(°C) to Fahrenheit(°F)
122+
/// @param temperature – The temperature in Celsius
123+
/// @returns The temperature converted to Fahrenheit
124+
FUNCTION CelsiusToFahrenheit = ( temperature: DOUBLE ) =>
125+
( temperature * ( 9 / 5 ) ) + 32
126+
```
127+
128+
Here is the technique adopted for parameters by Tabular Editor 3 in September 2025 release:
129+
```
130+
/// Convert from Celsius(°C) to Fahrenheit(°F)
131+
FUNCTION CelsiusToFahrenheit = (
132+
// The temperature in Celsius
133+
temperature: DOUBLE
134+
) =>
135+
( temperature * ( 9 / 5 ) ) + 32
136+
```

‎_mydocs/dax-style/index.md‎

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
---
2+
layout: page
3+
title: DAX Style
4+
published: true
5+
order: /dax-style
6+
next_reading: true
7+
next_reading_title: false
8+
---
9+
10+
SQLBI suggestions for writing DAX code:

0 commit comments

Comments
 (0)