Commit d6328185 authored by Mart Lubbers's avatar Mart Lubbers

Fix markdown

parent a4d33571
Pipeline #8200 failed with stage
in 1 minute and 17 seconds
The following guidelines should be adhered to when developing libraries for the
Clean Platform library collection.
== Type names ==
## Type names
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
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).
== Function names ==
## Function names
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.
== Module names ==
## Module names
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
......@@ -20,17 +23,18 @@ example provide a more friendly interface, you should prefix the name of that
module with an underscore character or place it in a separate Internal
== Argument order ==
## Argument order
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:
- State representing arguments such as the common *World type argument,
- 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.
== Comments ==
## Comments
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:
......@@ -47,11 +51,13 @@ Several JavaDoc like parameters are supported such as `@param`, `@result`,
`@type`, `@var` and `@representation. More info about this can be found
== Layout ==
## Layout
Tabs should be used for indentation. Spaces for alignment.
`where` clauses should not be indented.
== Exporting functions and types ===
## 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
......@@ -65,5 +71,5 @@ collisions, adhere to the following conventions:
Implementation modules may import anything they like.
== Implementing class instances and generic derives ==
## Implementing class instances and generic derives
Markdown is supported
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment