Unlike most other languages, Elm doesn’t use syntactic markers such as curly brackets, parentheses, or semicolons to specify code boundaries. It uses whitespace and indentation instead. There are situations where if we don’t place our code in a certain order or provide proper indentation, Elm will throw a syntax error. Let’s go through them one by one.
Let’s use an example from the Function section to understand the implications of using incorrect order and indentations when defining a function.
All Elm files begin with a
module definition. It’s perfectly fine to add comments above the
module definition, but no other code can go above it.
import lines are optional. If they’re included, they’re listed right below the
module definition. Both
import lines must start at the left most column. The top-level function definitions are placed below the
import lines. They too must start at the left most column. Later you will be introduced to other concepts in Elm such as
type that also go below the
Notice how two blank lines are used to separate the definition for functions
main? Because Elm doesn’t use delimiters such as curly braces to surround functions, using only a single blank line to separate definitions can make our code less readable. Elm borrowed this convention from Python, another great language. However, the
import lines are separated with only one blank line. These spacing rules are enforced by
elm-format. It is a little confusing that
elm-format uses two blank lines between some definitions, and one blank line between others. Maybe that will change by the time
1.0.0 version is out.
At the time of this writing,
elm-format uses four spaces to indent a function body. Because it’s still in alpha, don’t be surprised if it uses two spaces instead when
1.0.0 is out. In the earlier sections, you were led to believe that the body of a function,
case expressions must be indented with at least one space. That still holds true. Syntactically speaking, all Elm cares about is an indentation with at least one space. But, using more than one space improves the readability of our code.
If you’re interested, here is a vigorous debate between the Elm community members on whether to use two or four spaces for indentation. We programmers are so nitpicky, aren’t we?
If, Let, and Case Expression
if expression must be placed inside a function definition, otherwise Elm will throw an error.
The part after
then and final
else should be placed on the next line indented with four spaces. It’s perfectly fine to place an
if expression inside a
case expression as long as they themselves are placed inside a function. We already saw an example of this in the Let Expression section. Here it is again.
The body of
case expressions must also be indented with at least one space. As of this writing,
elm-format uses four spaces in both cases to improve the readability. The list below summarizes the indentation rules we have covered so far.
- Basic Indentation Rules
import, and top-level
functiondefinitions must start at the left most column.
- If an expression is split into multiple lines, the code that is part of that expression must be indented under that expression with at least one space.
- Parts of the expression that are grouped together should be indented with equal number of spaces. This rule is particularly important in a