Merge pull request #281211 from fricklerhandwerk/documentation-conventions

doc: reword documentation conventions

Changed files
+13 -9
doc
+13 -9
doc/README.md
···
In that case, please open an issue about the particular documentation convention and tag it with a "needs: documentation" label.
- Put each sentence in its own line.
-
This makes reviewing documentation much easier, since GitHub's review system is based on lines.
+
This makes reviews and suggestions much easier, since GitHub's review system is based on lines.
+
It also helps identifying long sentences at a glance.
-
- Use the admonitions syntax for any callouts and examples (see [section above](#admonitions)).
+
- Use the [admonition syntax](#admonitions) for callouts and examples.
-
- If you provide an example involving Nix code, make your example into a fully-working package (something that can be passed to `pkgs.callPackage`).
-
This will help others quickly test that the example works, and will also make it easier if we start automatically testing all example code to make sure it works.
-
For example, instead of providing something like:
+
- Provide at least one example per function, and make examples self-contained.
+
This is easier to understand for beginners.
+
It also helps with testing that it actually works – especially once we introduce automation.
-
```
+
Example code should be such that it can be passed to `pkgs.callPackage`.
+
Instead of something like:
+
+
```nix
pkgs.dockerTools.buildLayeredImage {
name = "hello";
contents = [ pkgs.hello ];
}
```
-
Provide something like:
+
Write something like:
-
```
+
```nix
{ dockerTools, hello }:
dockerTools.buildLayeredImage {
name = "hello";
···
: Tag of the generated image.
-
_Default value:_ the output path's hash.
+
_Default value:_ the output path's hash.
```