The VAR keyword introduces variables in an expression.
The syntax after VAR defines a variable, which can be consumed in following VAR statements or within the mandatory RETURN statement following the declaration of one or more variables.
If VAR is used in the DEFINE section of an EVALUATE statement, it can be used in any expression of the statement and the RETURN keyword cannot be used.

VAR <name> = <expression>
[VAR <name2> = <expression2> [...]]
RETURN <result_expression>

The expression is evaluated only once and assigned to the name in the scope of the expression where the VAR/RETURN expression is used.
The expression2 has access to name.
A variable nameN is visible in all the expressionN+1 of following variables defined within the same VAR/RETURN statement.
If an expression contains the definition of other variables in nested VAR/RETURN statements, the nested variables are not visible outside of the scope of expression. Indeed, the result_expression has access to all the variables (name, name2, …) defined in the VAR statement(s) before RETURN in the same statement, but it does not have access to variable defined in nested VAR/RETURN statements applied to assigned to variables.

The variable name cannot be a table name or a reserved keyword in DAX or MDX. When a new table is added to a model, it could break all the existing DAX expressions using the same name for a variable. To lower the chances of such an event, you should carefully name variables or use a prefix reserved for variables. DAX code generators commonly use a prefix like ‘_’ or ‘__’ to limit the likelihood of such an issue.

The actual evaluation of the variable is subject to possible optimizations in the query plan, which could remove unused variables or unused conditional branches as described in When are variables evaluated in DAX? article.