2.8 KB
Newer Older
1 2
The following guidelines should be adhered to when developing libraries for the
Clean Platform library collection.
3 4

== Type names ==
5 6
The names of types should be clear and informative, and should always start
with a capital.  If the name of a type consists of multiple words, each new
7 8
word should start with a capital.  Whenever the name is an abbreviation the
abbreviation should be written using only capitals (e.g. GUI,SQL,HTTP).
9 10

== Function names ==
Mart Lubbers's avatar
Mart Lubbers committed
11 12 13
Function names should be written in lowerCamelCase. By starting types and
constructors with a capital and, functions without one, the difference between
a constructor and a function is immediately clear for the reader of a program.
14 15

== Module names ==
16 17 18 19
For modules, the same guidelines apply as for naming types. Names should be
informative and preferably short. When a library module is not meant for direct
imports by end users, but should only used by experts in modules that for
example provide a more friendly interface, you should prefix the name of that
Mart Lubbers's avatar
Mart Lubbers committed
20 21
module with an underscore character or place it in a separate Internal
22 23

== Argument order ==
24 25 26
While there are no hard demands on the order in which you specify the arguments
of functions, there are two rules which make your functions easier to use and
somewhat more clear:

Mart Lubbers's avatar
Mart Lubbers committed
28 29 30 31
- State representing arguments such as the common *World type argument,
  should be at the end of the argument list.
- Arguments which are used as "options" in some way should be at the beginning
  of the arguments. This makes it easy to pass in options by currying.
32 33

== Comments ==
34 35 36
A concise description of the purpose of a function and the meaning of its input
and output parameters should be present in the .dcl file for all exported
functions. Comments are specified as follows:

Mart Lubbers's avatar
Mart Lubbers committed
 * This function is the identity.
41 42 43
id :: a -> a
id x = x
Mart Lubbers's avatar
Mart Lubbers committed

Mart Lubbers's avatar
Mart Lubbers committed
46 47 48
Several JavaDoc like parameters are supported such as `@param`, `@result`,
`@type`, `@var` and `@representation. More info about this can be found

== Layout ==
Mart Lubbers's avatar
Mart Lubbers committed
51 52
Tabs should be used for indentation. Spaces for alignment.
`where` clauses should not be indented.
53 54 55 56 57 58 59

== Exporting functions and types ===
Definition modules (.dcl) must be very specific about the modules they import
because everything imported in a definition module is exported as well,
increasing the chance of name collisions. To minimize the chance for
collisions, adhere to the following conventions:

Mart Lubbers's avatar
Mart Lubbers committed
60 61 62 63 64 65 66
- Explicitly import the types and classes you need for specifying the type
  signatures by using the "from ... import ..." notation.

- Only ever import an entire module with the "import ..." notation if you
  really truly want to re-export the entire module.

Implementation modules may import anything they like.

Mart Lubbers's avatar
Mart Lubbers committed
== Implementing class instances and generic derives ==