doc: Add a "Coding Style" section in 'HACKING'.
* HACKING (Coding Style): New section.
8 years ago
1 changed files
Download Patch File
Download Diff File
@ -88,6 +88,40 @@ firstname.lastname@example.org. Please write commit logs in the [[http://www.gnu.org/prep/s
As you become a regular contributor, you may find it convenient to have write
access to the repository (see below.)
* Coding Style
In general our code follows the [[info:standards][GNU Coding Standards]] (GCS). However, the GCS
do not say much about Scheme, so here are some additional rules.
** Programming Paradigm
Scheme code in Guix is written in a purely functional style. One exception is
code that involves input/output, and procedures that implement low-level
concepts, such as the ‘memoize’ procedure.
Guile modules that are meant to be used on the builder side must live in the
(guix build …) name space. They must not refer to other Guix or GNU modules.
However, it is OK for a “host-side” module to use a build-side module.
Modules that deal with the broader GNU system should be in the (gnu …) name
space rather than (guix …).
** Formatting Code
When writing Scheme code, we follow common wisdom among Scheme programmers.
In general, we follow the [[http://mumble.net/~campbell/scheme/style.txt][Riastradh's Lisp Style Rules]]. This document happens
to describe the conventions mostly used in Guile’s code too. It is very
thoughtful and well written, so please do read it.
In addition, we require all top-level procedures to carry a docstring. This
requirement can be relaxed for simple private procedures in the (guix build …)
name space, though.
Procedures should not have more than four positional parameters. Use keyword
parameters for procedures that take more than four parameters.
* Commit Access
For frequent contributors, having write access to the repository is