Refine language and punctuation in user-defined functions documentation for clarity and consistency

Author: marcosqlbi

_mydocs/dax-internals/user-defined-functions/calculate-modifiers.md

@@ -5,7 +5,7 @@ published:  true
 order:      /04
 ---
 
-Because UDFs expand as macros, a function body can contain expressions that are only syntactically valid in a specific calling position. In particular, a function can "return" a CALCULATE modifier — provided the function is always called as a filter argument of `CALCULATE` or `CALCULATETABLE`.
+Because UDFs expand as macros, a function body can contain expressions that are only syntactically valid in a specific calling position. In particular, a function can "return" a CALCULATE modifier, provided the function is always called as a filter argument of `CALCULATE` or `CALCULATETABLE`.
 
 ## Mechanism
 
@@ -74,4 +74,4 @@ This pattern returns a scalar and has no calling-position restriction. The choic
 
 ## Practical use case
 
-A common application is centralizing the list of **filter-keep columns** — columns on a date table whose filters must be removed when computing a reference date, but preserved by time intelligence functions applied afterward. Placing the `REMOVEFILTERS` list in a function prevents it from being duplicated across many measures and simplifies maintenance when the column list changes.
+A common application is centralizing the list of **filter-keep columns**: columns on a date table whose filters must be removed when computing a reference date but preserved by time intelligence functions applied afterward. Placing the `REMOVEFILTERS` list in a function prevents it from being duplicated across many measures and simplifies maintenance when the column list changes.

_mydocs/dax-internals/user-defined-functions/index.md

@@ -7,7 +7,7 @@ next_reading: true
 next_reading_title: false
 ---
 
-A DAX user-defined function (UDF) is a named, reusable expression declared with the `DEFINE FUNCTION` statement. UDFs are not subroutines invoked on a call stack; they expand inline at the call site as macros. The function body is substituted wherever the function is called, which means that expressions only valid in certain positions — such as CALCULATE modifiers — can be encapsulated inside a function and remain valid after expansion.
+A DAX user-defined function (UDF) is a named, reusable expression declared with the `DEFINE FUNCTION` statement. UDFs are not subroutines invoked on a call stack; they expand inline at the call site as macros. The function body is substituted wherever the function is called, which means that expressions only valid in certain positions (such as CALCULATE modifiers) can be encapsulated inside a function and remain valid after expansion.
 
 UDFs can be defined at query level inside a `DEFINE` block or stored in a semantic model and shared across all measures and calculated columns in that model.
 

_mydocs/dax-internals/user-defined-functions/model-dependency.md

@@ -5,7 +5,7 @@ published:  true
 order:      /05
 ---
 
-A UDF is **model-dependent** when its body references model objects directly — tables, columns, measures, or calendars — by name. It is **model-independent** when all such references arrive exclusively through parameters, making the function portable across semantic models without modification.
+A UDF is **model-dependent** when its body references model objects directly (tables, columns, measures, or calendars) by name. It is **model-independent** when all such references arrive exclusively through parameters, making the function portable across semantic models without modification.
 
 ## Hidden dependencies
 

_mydocs/dax-internals/user-defined-functions/optional-parameters.md

@@ -35,7 +35,7 @@ Increment ( 10, 20 )  -- y is 20; returns 30
 
 ### Skipping a middle parameter
 
-To skip an optional parameter that is not the last one, write an **empty position** — a comma with no value before it:
+To skip an optional parameter that is not the last one, write an **empty position**: a comma with no value before it:
 
 ```dax
 IncrementLimit ( 5, , 20 )  -- y uses its default; limit is 20
@@ -45,7 +45,7 @@ IncrementLimit ( 5, , 20 )  -- y uses its default; limit is 20
 
 Optional parameters can appear in any position in the signature; required parameters can follow optional ones. Callers can always reach a required parameter by leaving an empty position for each optional parameter before it (`MyFunc ( 1, , 3 )` omits the second argument).
 
-The minimum number of arguments a caller must supply — the function's arity — is determined by the **position of the rightmost required parameter**. If a function has three parameters and only the second is optional, callers must still supply at least three arguments: there is no way to omit the third, because it is required and comes last.
+The minimum number of arguments a caller must supply (the function's arity) is determined by the **position of the rightmost required parameter**. If a function has three parameters and only the second is optional, callers must still supply at least three arguments: there is no way to omit the third, because it is required and comes last.
 
 The recommended practice is: **once a parameter is optional, all following parameters should also be optional.** Placing a required parameter after an optional one forces callers to write empty positions just to reach it, which is harder to read and easy to get wrong.
 
@@ -80,7 +80,7 @@ Like the function expression body, a default expression inherits the **filter co
 
 ### Scope
 
-A default expression can only reference names — columns, tables, measures, variables, functions — that are **visible at the point where the UDF is defined**, not where it is called. It cannot reference another parameter of the same function.
+A default expression can only reference names (columns, tables, measures, variables, functions) that are **visible at the point where the UDF is defined**, not where it is called. It cannot reference another parameter of the same function.
 
 ### Type
 

_mydocs/dax-internals/user-defined-functions/parameter-types.md

@@ -86,20 +86,20 @@ FUNCTION F = ( a : VAL, b : EXPR ) => ...
 
 Type checking and coercion apply differently depending on the parameter category:
 
-**Scalar subtypes** (`INT64`, `DECIMAL`, `DOUBLE`, etc.) do not reject incompatible arguments — they coerce them. Each argument is independently converted to the declared type before the function body runs. No error is raised; see the coercion note under *Scalar subtypes* above.
+**Scalar subtypes** (`INT64`, `DECIMAL`, `DOUBLE`, etc.) do not reject incompatible arguments; they coerce them. Each argument is independently converted to the declared type before the function body runs. No error is raised; see the coercion note under *Scalar subtypes* above.
 
 **Reference types** (`MEASUREREF`, `COLUMNREF`, `TABLEREF`, `CALENDARREF`) perform genuine type checking at call time. Passing an incompatible expression produces an error that identifies the expected and received types, for example: *"An invalid argument type was passed into parameter 'amountMeasure' of the user-defined function. Expected 'MEASUREREF' but got 'SCALAR'."* There is a known limitation for `COLUMNREF`: when a column reference is invalid, the internal syntax error from the function body surfaces before any custom validation error the function author may have written.
 
-**`ANYREF`** performs no type checking. An incompatible argument may produce confusing errors deep inside the function body or, in the worst case, incorrect results with no error at all. Functions using `ANYREF` must handle the general case defensively — for example, wrapping every reference to the parameter in `CALCULATE` to guarantee context transition regardless of what was passed.
+**`ANYREF`** performs no type checking. An incompatible argument may produce confusing errors deep inside the function body or, in the worst case, incorrect results with no error at all. Functions using `ANYREF` must handle the general case defensively, for example by wrapping every reference to the parameter in `CALCULATE` to guarantee context transition regardless of what was passed.
 
 ## Introspection functions
 
 Two functions are available for use inside a function body with `COLUMNREF` or `TABLEREF` parameters:
 
-- **`TABLEOF ( columnRef )`** — returns the table in which the referenced column is defined.
-- **`NAMEOF ( columnRef )`** — returns the column's fully qualified name as a string.
+- **`TABLEOF ( columnRef )`**: returns the table in which the referenced column is defined.
+- **`NAMEOF ( columnRef )`**: returns the column's fully qualified name as a string.
 
-These functions are intended to support runtime validation — for example, checking that two `COLUMNREF` parameters belong to the same table:
+These functions are intended to support runtime validation, for example checking that two `COLUMNREF` parameters belong to the same table:
 
 ```dax
 IF (

_mydocs/dax-internals/user-defined-functions/syntax.md

@@ -40,22 +40,22 @@ Function names use **Pascal case** to distinguish user-defined functions from bu
 
 UDFs can be defined in two places:
 
-- **Query level** — inside the `DEFINE` block of a DAX query. The function is visible only within that query.
-- **Model level** — stored as a named object in a semantic model. The function is visible from any measure, calculated column, or calculated table in that model, and from DAX queries run against it.
+- **Query level**: inside the `DEFINE` block of a DAX query. The function is visible only within that query.
+- **Model level**: stored as a named object in a semantic model. The function is visible from any measure, calculated column, or calculated table in that model, and from DAX queries run against it.
 
 ## Return type
 
 A function can return:
 
-- A **scalar value** — usable anywhere a scalar expression is valid.
-- A **table** — usable anywhere a table expression is valid.
-- A **CALCULATE modifier** (e.g., `REMOVEFILTERS`) — only valid as a filter argument inside `CALCULATE` or `CALCULATETABLE`. This special case is possible because UDFs expand as macros; see [Returning CALCULATE modifiers](calculate-modifiers.md).
+- A **scalar value**: usable anywhere a scalar expression is valid.
+- A **table**: usable anywhere a table expression is valid.
+- A **CALCULATE modifier** (e.g., `REMOVEFILTERS`): only valid as a filter argument inside `CALCULATE` or `CALCULATETABLE`. This special case is possible because UDFs expand as macros; see [Returning CALCULATE modifiers](calculate-modifiers.md).
 
 ## Macro-expansion semantics
 
 UDFs are not subroutines. There is no separate call stack or isolated execution context. When a UDF is called, its body is substituted inline at the call site, with each argument replacing its corresponding parameter according to the parameter's passing mode. The result is semantically identical to having written the substituted expression directly at the call site.
 
-A consequence is that the function body may contain language constructs — such as CALCULATE modifiers — that are only syntactically valid in certain positions, provided the function is always called from a position where those constructs are valid.
+A consequence is that the function body may contain language constructs (such as CALCULATE modifiers) that are only syntactically valid in certain positions, provided the function is always called from a position where those constructs are valid.
 
 ## Limitations