Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Write best practices and style guide #904

Merged
merged 38 commits into from
Sep 30, 2023
Merged
Changes from 35 commits
Commits
Show all changes
38 commits
Select commit Hold shift + click to select a range
9c2037d
feat(practices): options and parameters
May 10, 2023
efc10cb
feat(practices): require docs for exported things
May 11, 2023
1338aac
feat(practices): explain formatting
May 11, 2023
1b63ecf
feat(practices): add example
May 11, 2023
d649d4a
feat(practices): extend first formatting rule
May 11, 2023
89bf85b
feat(practices): rewrite formatting rules
May 11, 2023
1e8c1d8
feat(practices): add examples
May 11, 2023
062e1d0
feat(practices): note about keeping indent
May 11, 2023
ecfb91c
feat(practices): add list formatting
May 11, 2023
8980677
feat(practices): make rules sound more polite
May 11, 2023
d8aca9f
feat(practices): add note
May 11, 2023
ef39d60
feat(practices): clarify one-line format rules
May 11, 2023
3fdc3d3
feat(practice): clean-up
May 11, 2023
aedbc9c
fix(practices): remove duplicates
May 11, 2023
930df0d
feat(practices): update examples
May 11, 2023
0639f71
feat(practices): recommend omit commas
May 11, 2023
ca6ce66
feat(practices): allow short format more
May 11, 2023
a2dac57
feat(practices): make intro less authoritative
May 13, 2023
b8de74f
feat(practices): move comments on separate lines
May 13, 2023
d18a100
feat(practices): note about escape sequences
May 13, 2023
aef4ac8
feat(practices): unify collection syntax
May 13, 2023
1cfefea
feat(practices): narrow down amount of args
May 13, 2023
6a22d9d
fix(practices): deduplicate terms
May 13, 2023
5efba81
fix(practices): require trailing space omission
May 13, 2023
c9f61d2
tweaked some grammar, removed some optional commas
fdncred May 13, 2023
cd765c2
feat(practices): join sections
May 14, 2023
2ffc8ab
Merge branch 'feature/add-best-practices' of https://github.com/Emily…
May 14, 2023
6852d1e
feat(practices): clarify when use and what format
May 14, 2023
80af021
feat(practices): update examples
May 17, 2023
4269691
feat(practices): dealing with parenthesis
May 17, 2023
300cf67
feat(practices): forbid consecutive spaces
May 17, 2023
4b47366
feat(practices): add spacing between constructs
May 17, 2023
88565ff
feat(practices): simplify rules
May 17, 2023
d969521
feat(practices): clarify rules for parenthesis
May 17, 2023
ebf66a4
feat(practices): spacing when no params defined
May 17, 2023
3616f66
Update book/style_guide.md
May 17, 2023
8d01d4f
Merge branch 'main' into feature/add-best-practices
Jun 18, 2023
a433170
Merge branch 'feature/add-best-practices' of https://github.com/Emily…
Jun 18, 2023
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
194 changes: 194 additions & 0 deletions book/style_guide.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,194 @@
# 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:

```nushell
'Hello, Nushell! This is a gradient.' | ansi gradient --fgstart '0x40c9ff' --fgend '0xe81cff'
```

Incorrect:

```nushell
# - two many spaces after "|": 2 instead of 1
EmilyGraceSeville7cf marked this conversation as resolved.
Show resolved Hide resolved
'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:

```nushell
[[status]; [UP] [UP]] | all {|el| $el.status == UP }
[1 2 3 4] | reduce {|it, acc| $it + $acc }
[1 2 3 4] | reduce {|it acc| $it + $acc }
{x: 1, y: 2}
{x: 1 y: 2}
[1 2] | zip [3 4]
[]
(1 + 2) * 3
```

Incorrect:

```nushell
# 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 {|it , acc| $it + $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

Rules:

1. general:
1. **It's required to omit** trailing spaces.
2. block and closure bodies:
1. **It's recommended to** put each body pipeline on a separate line.
3. records:
1. **It's recommended to** put each record key-value pair on separate line.
4. lists:
1. **It's recommended to** put each list item on separate line.
5. surrounding constructs:
1. **It's recommended to** put one `\n` before opening square `[`, curly brace `{`, or parenthesis `(` if preceding symbol is not the and applying this rule produce line with a singular parenthesis.
2. **It's recommended to** put one `\n` after closing square `]`, curly brace `}`, or parenthesis `)` if following symbol is not the same and applying this rule produce line with a singular parenthesis.

Correct:

```nushell
[[status]; [UP] [UP]] | all {|el|
$el.status == UP
}

[1 2 3 4] | reduce {|it, acc|
$it + $acc
}
amtoine marked this conversation as resolved.
Show resolved Hide resolved

{x: 1, y: 2}

[
{name: "Teresa", age: 24},
{name: "Thomas", age: 26}
]

let selectedProfile = (for it in ($credentials | transpose name credentials) {
echo $it.name
})
```

Incorrect:

```nushell
# too many spaces before "|el|": no space is allowed (like in one-line format)
[[status]; [UP] [UP]] | all { |el|
# too few "\n" before "}": one "\n" is required
$el.status == UP}

# too many spaces before "2": one space is required (like in one-line format)
[1 2 3 4] | reduce {|it, acc|
$it + $acc
}

{
# too many "\n" before "x": one-line format required as no nested lists or record exist
x: 1,
y: 2
}

# too few "\n" before "{": multi-line format required as there are two nested records
[{name: "Teresa", age: 24},
{name: "Thomas", age: 26}]

let selectedProfile = (
# too many "\n" before "foo": no "\n" is allowed
for it in ($credentials | transpose name credentials) {
echo $it.name
})
```

## Options and parameters of custom commands

- **It's recommended to** keep count of all positional parameters less than or equal to 2, for remaining inputs use options. Assume that command can expect source and destination parameter, like `mv`: source and target file or directory.
- **It's recommended to** use positional parameters unless they can't be used due to rules listed here or technical restrictions.
For instance, when there are several kinds of optional parameters (but at least one parameter should be provided)
use options. Great example of this is `ansi gradient` command where at least foreground or background must be passed.
- **It's recommended to** provide both long and short options.

## Documentation

- **It's recommended to** provide documentation for all exported entities (like custom commands) and their
inputs (like custom command parameters and options).