4 The Compiler Company Styleguide)}}}
6 As an organization we maintain a styleguide
[fn:1] which lists all of
7 the style guidelines we use for our code. If you are contributing to
8 one of our projects, you should review and understand the relevant
11 You should also review the
[[file:ulang.org][ulang]] document, which may shine some light
12 on code comments and developer docs.
14 [fn:1] https:
//google.github.io/styleguide/ 23 - start every source-file with a header comment
24 - use outline headings to organize your program
25 - use ulang-comments as needed for referencing bugs, notes, etc.
26 - inline documentation should be declarative. your code explains your
28 - variables, imports, and exports belong at the top of a file
29 - =main= functions belong at the bottom of a file
30 - use LSP wherever possible (eglot, slime)
32 - prefer symbol docs to comments
33 - use stdin/stdout/stderr correctly - see
[[https://zenodo.org/records/3414191][CDR-11]] 34 - always prefer
=core= libraries over vendored dependencies
35 - use the compiler built-ins - if a function or class is generally
36 useful, add it to the core
37 - use conditions, restarts, and error handling where appropriate
38 - save type declarations and hairy optimizations for when the API is
40 - don't be afraid of macros
42 - don't make
=mod.rs= files
43 - use the
=foo.rs=,
=foo/*= pattern instead
44 - derive
=Debug= and
=Clone= wherever possible
45 - write a sensible
=Display= impl
46 - use generics where appropriate:
=foo<P:AsRef<Path>>(path:P){p.as_ref();}=
