Chapter 10. Coding conventions

10.1. Syntax

Use 2 spaces of indentation per indentation level in Nix expressions, 4 spaces in shell scripts.
Do not use tab characters, i.e. configure your editor to use soft tabs. For instance, use (setq-default indent-tabs-mode nil) in Emacs. Everybody has different tab settings so it’s asking for trouble.
Use lowerCamelCase for variable names, not UpperCamelCase. TODO: naming of attributes in all-packages.nix?
Function calls with attribute set arguments are written as
```
foo {
  arg = ...;
}
```
not
```
foo
{
  arg = ...;
}
```
Also fine is
```
foo { arg = ...; }
```
if it's a short call.

In attribute sets or lists that span multiple lines, the attribute names or list elements should be aligned:

# A long list.
list =
  [ elem1
    elem2
    elem3
  ];

# A long attribute set.
attrs =
  { attr1 = short_expr;
    attr2 =
      if true then big_expr else big_expr;
  };

# Alternatively:
attrs = {
  attr1 = short_expr;
  attr2 =
    if true then big_expr else big_expr;
};

Short lists or attribute sets can be written on one line:

# A short list.
list = [ elem1 elem2 elem3 ];

# A short set.
attrs = { x = 1280; y = 1024; };

Breaking in the middle of a function argument can give hard-to-read code, like

someFunction { x = 1280;
  y = 1024; } otherArg
  yetAnotherArg

(especially if the argument is very large, spanning multiple lines).

Better:

someFunction
  { x = 1280; y = 1024; }
  otherArg
  yetAnotherArg

let res = { x = 1280; y = 1024; };
in someFunction res otherArg yetAnotherArg

The bodies of functions, asserts, and withs are not indented to prevent a lot of superfluous indentation levels, i.e.

{ arg1, arg2 }:
assert system == "i686-linux";
stdenv.mkDerivation { ...

not

{ arg1, arg2 }:
  assert system == "i686-linux";
    stdenv.mkDerivation { ...

Function formal arguments are written as:
```
{ arg1, arg2, arg3 }:
```
but if they don't fit on one line they're written as:
```
{ arg1, arg2, arg3
, arg4, ...
, # Some comment...
  argN
}:
```

Functions should list their expected arguments as precisely as possible. That is, write

{ stdenv, fetchurl, perl }: ...

instead of

args: with args; ...

{ stdenv, fetchurl, perl, ... }: ...

For functions that are truly generic in the number of arguments (such as wrappers around mkDerivation) that have some required arguments, you should write them using an @-pattern:

{ stdenv, doCoverageAnalysis ? false, ... } @ args:

stdenv.mkDerivation (args // {
  ... if doCoverageAnalysis then "bla" else "" ...
})

instead of

args:

args.stdenv.mkDerivation (args // {
  ... if args ? doCoverageAnalysis && args.doCoverageAnalysis then "bla" else "" ...
})