agentleFS
VyrnexisVyrnexis/nim-agent-template/skills/nim-style-guide/SKILL.md

nim-style-guide

Skill4 starsChanged 3 months agoMITView on GitHub

Write clear, consistent Nim code in a simple stdlib-aligned style, covering imports, naming, proc vs func vs template choices, local variables, constructors, formatting, and control flow. Use when writing new Nim code or reviewing a Nim module for readability, consistency, and low-noise style decisions.

1 other project uses a version of this, 1 of them edited.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

38 rules. About 0 are common, 12 are distinctive, and 26 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈12

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 26

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Keep lines at or below 100 characters.

    line 13
  2. Distinctive:

    Use ordinary spacing instead of aligning columns by hand.

    line 14
  3. Very specific:

    Write range operators compactly: a..b, a..<b, and a..^b.

    line 15
  4. Very specific:

    Use std/... imports for stdlib modules.

    line 23
  5. Very specific:

    Use from foo import bar, baz when you only need a small API slice.

    line 25
  6. Very specific:

    Use qualified module.symbol access only to resolve genuine name conflicts between imported modules.

    line 28
  7. Very specific:

    Use ALL_UPPERCASE only when preserving names from a C or C++ wrapper.

    line 35
  8. Very specific:

    Use normal word casing such as parseUrl and httpStatus.

    line 36
  9. Very specific:

    Do not stutter the type name into its fields.

    line 37
  10. Very specific:

    Use short names for parameters and locals that echo the type, as in inv: Inventory or s: Session.

    line 38
  11. Very specific:

    Use established stdlib names when behavior matches: initX, newX, find, contains, add, cmp, len, cap, items, pairs, incl, and excl.

    line 46
  12. Very specific:

    Use func for pure helpers and pure accessors when checked purity helps.

    line 56
  13. Very specific:

    Use template when call-site substitution, lazy evaluation, or a control-flow abstraction is required.

    line 57
  14. Very specific:

    Prefer proc and func over method.

    line 59
  15. Distinctive:

    Prefer top-level helpers for reusable logic.

    line 60
  16. Distinctive:

    Use a nested proc when the logic is truly local or when you want a closure.

    line 61
  17. Very specific:

    Use macro only when syntax transformation is required.

    line 63
  18. Distinctive:

    Prefer compact wrapped calls over one-argument-per-line call blocks.

    line 68
  19. Distinctive:

    Use UFCS when it reads like an accessor.

    line 69
  20. Very specific:

    Write typeof(x), not the historical type(x).

    line 70
  21. Very specific:

    Write enum values unqualified (north, not Direction.north).

    line 71
  22. Very specific:

    Use let by default.

    line 72
  23. Very specific:

    Use var only for values that mutate.

    line 73
  24. Distinctive:

    Keep local declarations close to first use.

    line 74
  25. Distinctive:

    Keep public and reusable types at module scope.

    line 75
  26. Very specific:

    Write x notin items, not not x in items.

    line 105
  27. Very specific:

    Use """...""" triple-quoted literals instead of "a\n" & "b\n" concatenation for multiline values.

    line 118
  28. Very specific:

    Start with a newline right after """.

    line 120
  29. Distinctive:

    Use structured control flow.

    line 127
  30. Very specific:

    If the body is exactly one expression, end with that expression, as in func len(b: Bag): int = b.items.len

    line 128
  31. Distinctive:

    When a loop finds the return value, return it directly instead of using a flag.

    line 131
  32. Very specific:

    Do not use continue. Put the remaining loop body inside a condition.

    line 132
  33. Very specific:

    Start with proc. Switch to func for a useful purity contract, template for call-site substitution, and macro for syntax transformation.

    line 137
  34. Very specific:

    Write imports and names. Use std/...

    line 140
  35. Very specific:

    Use std/... imports, narrow imports when practical, and keep names in normal Nim casing.

    line 141
  36. Distinctive:

    Use structured control flow.

    line 143
  37. Very specific:

    Use let by default, keep locals near first use, and keep reusable helpers at module scope.

    line 145
  38. Distinctive:

    Remove unused imports, dead helpers, column alignment, and stretched call formatting.

    line 147

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Nim Style Guide

Rules

Formatting

  • Indent blocks with 2 spaces and use spaces instead of tab characters.
  • Keep lines at or below 100 characters.
  • Use ordinary spacing instead of aligning columns by hand.
  • Write range operators compactly: a..b, a..<b, and a..^b. Add spaces when an operand contains an operator, as in a .. -3.
  • In range type constructors, use ..: range[0..n-1] is valid; range[0..<n] is invalid.
  • Indent wrapped declarations, calls, and conditions one extra level.

Imports

  • Use std/... imports for stdlib modules.
  • Group imports from the same directory: import std/[a, b, c], import lib/[x, y, z].
  • Use from foo import bar, baz when you only need a small API slice.
  • import brings symbols into scope without qualification.
  • export takes only the module name: export baz, not export foo/bar/baz.
  • Use qualified module.symbol access only to resolve genuine name conflicts between imported modules.

Naming

  • Types use PascalCase.
  • Procs, funcs, iterators, templates, vars, and fields use camelCase.
  • Constants default to PascalCase; camelCase is also allowed.
  • Use ALL_UPPERCASE only when preserving names from a C or C++ wrapper.
  • Use normal word casing such as parseUrl and httpStatus.
  • Do not stutter the type name into its fields; Product.name, not Product.productName.
  • Use short names for parameters and locals that echo the type, as in inv: Inventory or s: Session.
  • Give the most-used representation the base type name. Suffix the others with Obj, Ref, or Ptr.
  • Suffix catchable exception types with Error and programming-bug defect types with Defect.
  • For non-pure enums, prefix values such as pcFile. For pure enums, use PascalCase.
  • Prefix mutable views with m, as in mitems and mpairs.
  • Pair in-place and copied transforms as reverse and reversed. If the copy name already exists, suffix the in-place form with In, as in replaceIn.
  • Name domain predicates subject-first, as in fileExists, not existsFile.
  • Use established stdlib names when behavior matches: initX, newX, find, contains, add, cmp, len, cap, items, pairs, incl, and excl.
  • Name a cheap, side-effect-free field getter foo. Use getFoo when the operation has side effects or is not O(1).
  • Pair foo with foo= and getFoo with setFoo.
  • Accessors may share the field's name, no collision.

Proc, Func, Template, Macro

  • Default to proc.
  • Use func for pure helpers and pure accessors when checked purity helps.
  • Use template when call-site substitution, lazy evaluation, or a control-flow abstraction is required.
  • Prefer proc and func over method. Use method only when you need runtime dispatch.
  • Prefer top-level helpers for reusable logic.
  • Use a nested proc when the logic is truly local or when you want a closure.
  • A nested proc may capture outer locals. If a nested proc must stay non-capturing, mark it {.nimcall.}.
  • Use macro only when syntax transformation is required.
  • Mark one-expression forwarders and field accessors {.inline.}.

Calls, Locals, And Types

  • Prefer compact wrapped calls over one-argument-per-line call blocks.
  • Use UFCS when it reads like an accessor.
  • Write typeof(x), not the historical type(x).
  • Write enum values unqualified (north, not Direction.north); qualify only on ambiguity.
  • Use let by default.
  • Use var only for values that mutate.
  • Keep local declarations close to first use.
  • Keep public and reusable types at module scope.
  • Group related fields with the same type when it improves readability.
  • Initialize result explicitly; prefer object constructors (TypeName(field: value)) over field-by-field assignment.
  • Omit fields that should keep their declared defaults.
  • T() works only for objects; arrays use arrayWith, tuples use literals, strings/seqs use ""/@[], default(T) as fallback.

Parsing-Sensitive Whitespace

These whitespace choices change how Nim parses code:

  • Attach [ to a type name.
    • array[N, T] compiles. array [N, T] does not.
    • The same applies to seq[T], Table[K, V], etc.
  • Attach ( to a callable name for a parenthesized call.
    • foo(1, 2) passes two int arguments.
    • foo (1, 2) passes a single (int, int) tuple. Nim treats the parenthesized comma-list as a tuple constructor.
  • Do not use command-call syntax with comparisons or nested calls.
    • foo 1 == 1 parses like foo(1 == 1), not foo(1) == 1.
    • outer(inner 1, 1) parses as outer(inner(1), 1), not outer(inner(1, 1)).
  • Use [:T] for explicit generic parameters in UFCS calls.
    • x.p[:T]() rewrites to p[T](x).
    • x.p[T]() parses as (x.p)[T](), not a generic instantiation.
  • Group negated compound expressions.
    • Parenthesize compound operands of not: not a or b parses as (not a) or b, so write not (a or b) and not (x < y).
    • Write x notin items, not not x in items.

Line Continuation

Nim has no line-continuation character. Break expressions after an operator or comma, or within open delimiters such as (), [], and {}. Indent the continued line further than the statement that started it.

For constructs with a body, double indentation can distinguish continuation lines from the body.

Multiline Strings

  • Use """...""" triple-quoted literals instead of "a\n" & "b\n" concatenation for multiline values.
  • Start with a newline right after """. That newline is stripped, so the value is identical; the content aligns with the next line.

See references/multiline_strings.md.

Control Flow

  • Use structured control flow.
  • If the body is exactly one expression, end with that expression, as in func len(b: Bag): int = b.items.len
  • Otherwise assign the return value to result explicitly: as a default at the start, at the end, or once per branch.
  • A default result may be overridden by the branch that produces the value.
  • When a loop finds the return value, return it directly instead of using a flag.
  • Do not use continue. Put the remaining loop body inside a condition.

Workflow

  1. Pick the callable kind. Start with proc. Switch to func for a useful purity contract, template for call-site substitution, and macro for syntax transformation. Choose method for runtime dispatch.
  2. Write imports and names. Use std/... imports, narrow imports when practical, and keep names in normal Nim casing.
  3. Shape the control flow. Use structured control flow. Return directly when a loop finds its result.
  4. Clean up locals and constructors. Use let by default, keep locals near first use, and keep reusable helpers at module scope.
  5. Remove noise. Remove unused imports, dead helpers, column alignment, and stretched call formatting.

Common Mistakes

MistakeWhy it is wrong
Using method as the default callable kindIt adds runtime dispatch where a plain proc or func would usually be clearer.
Hiding reusable helpers inside another procIt makes the helper harder to reuse and easier to turn into an accidental closure.
Writing one argument per line by defaultIt adds vertical noise without adding structure.
Using var for values that never mutateIt hides which locals actually change.
Assuming {.pure.} requires Type.valuePure enum values may be unqualified.
Turning every branch into an early return in a multi-step procIt makes the normal path harder to scan.
Using continueA structured branch keeps the loop invariant visible.

References

  • references/core_patterns.md — General style patterns for imports, callable kinds, wrapping, locals, and constructors.
  • references/multiline_strings.md — Whitespace-preserving triple-quoted strings, joins, and dedenting.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.