# Let rules

## Prefer explicit dependencies over shared convenience bindings

### Rule

Do not add a `let` binding only to let sibling values share one expression.
Apply this rule only when one sibling value clearly owns the concept.
When one sibling value owns the concept, reference that sibling value directly.
When a flake output owns the public value, reference that output through `self`.
Do not make an output attrset recursive only to reference sibling outputs.
Do not apply this rule when a binding names a local constant used to keep sibling assignments in sync.

### Rationale

Shared convenience bindings hide dependency direction.
Explicit references show which value owns a concept and which value consumes it.

## Order `let` bindings by dependency

### Rule

Define a `let` binding before other bindings that reference it.
Use forward references only for intentional recursion or fixed-point wiring.

### Rationale

Nix permits recursive `let` bindings.
Top-down dependency order makes ordinary wiring easier to read.
This rule can become a linter rule because binding references are mechanically detectable.