# Best Practices
This page is a working document collecting syntax guidelines and best practices we have discovered so far.
The goal of this document is to eventually land on a canonical Nushell code style, but as for now it is still work in
progress and subject to change. We welcome discussion and contributions.
Keep in mind that these guidelines are not required to be used in external repositories (not ours), you can change them in the
way you want, but please be consistent and follow your rules.
All escape sequences should not be interpreted literally, unless directed to do so. In other words,
treat something like `\n` like the new line character and not a literal slash followed by `n`.
## Formatting
### Defaults
**It's recommended to** assume that by default no spaces or tabs allowed, but the following rules define where they are allowed.
### Basic
- **It's recommended to** put one space before and after pipe `|` symbol, commands, subcommands, their options and arguments.
- **It's recommended to** never put several consecutive spaces unless they are part of string.
- **It's recommended to** omit commas between list items.
Correct:
```nu
'Hello, Nushell! This is a gradient.' | ansi gradient --fgstart '0x40c9ff' --fgend '0xe81cff'
```
Incorrect:
```nu
# - too many spaces after "|": 2 instead of 1
'Hello, Nushell! This is a gradient.' | ansi gradient --fgstart '0x40c9ff' --fgend '0xe81cff'
```
#### One-line Format
One-line format is a format for writing all commands in one line.
**It's recommended to** default to this format:
1. unless you are writing scripts
2. in scripts for lists and records unless they either:
1. more than 80 characters long
2. contain nested lists or records
3. for pipelines less than 80 characters long not containing items should be formatted with
a long format
Rules:
1. parameters:
1. **It's recommended to** put one space after comma `,` after block or closure parameter.
2. **It's recommended to** put one space after pipe `|` symbol denoting block or closure parameter list end.
2. block and closure bodies:
1. **It's recommended to** put one space after opening block or closure curly brace `{` if no explicit parameters defined.
2. **It's recommended to** put one space before closing block or closure curly brace `}`.
3. records:
1. **It's recommended to** put one space after `:` after record key.
2. **It's recommended to** put one space after comma `,` after key value.
4. lists:
1. **It's recommended to** put one space after comma `,` after list value.
5. surrounding constructs:
1. **It's recommended to** put one space before opening square `[`, curly brace `{`, or parenthesis `(` if preceding symbol is not the same.
2. **It's recommended to** put one space after closing square `]`, curly brace `}`, or parenthesis `)` if following symbol is not the same.
Correct:
```nu
[[status]; [UP] [UP]] | all {|el| $el.status == UP }
[1 2 3 4] | reduce {|elt, acc| $elt + $acc }
[1 2 3 4] | reduce {|elt acc| $elt + $acc }
{x: 1, y: 2}
{x: 1 y: 2}
[1 2] | zip [3 4]
[]
(1 + 2) * 3
```
Incorrect:
```nu
# too many spaces before "|el|": no space is allowed
[[status]; [UP] [UP]] | all { |el| $el.status == UP }
# too many spaces before ",": no space is allowed
[1 2 3 4] | reduce {|elt , acc| $elt + $acc }
# too many spaces before "x": no space is allowed
{ x: 1, y: 2}
# too many spaces before "[3": one space is required
[1 2] | zip [3 4]
# too many spaces before "]": no space is allowed
[ ]
# too many spaces before ")": no space is allowed
(1 + 2 ) * 3
```
#### Multi-line Format
Multi-line format is a format for writing all commands in several lines. It inherits all rules from one-line format
and modifies them slightly.
**It's recommended to** default to this format:
1. while you are writing scripts
2. in scripts for lists and records while they either:
1. more than 80 characters long
2. contain nested lists or records
3. for pipelines more 80 characters long