Commit a4d33571 authored by Mart Lubbers's avatar Mart Lubbers

first update for Standards

parent 61ca4af2
Pipeline #8198 failed with stage
in 1 minute and 22 seconds
......@@ -8,48 +8,48 @@ 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 should *not* start with a capital, but when a function consists
of multiple words, each new word, except the first one should start with a
capital. 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.
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 ==
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
module with an underscore character.
module with an underscore character or place it in a separate Internal
submodule.
== 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,
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.
- 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 ==
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:
```
/**
* This function is the identity.
*/
id :: a -> a
id x = x
```
The @param notation (similar to JavaDocs) can be used to clarify the arguments
separately.
Several JavaDoc like parameters are supported such as `@param`, `@result`,
`@type`, `@var` and `@representation. More info about this can be found
[here](https://github.com/clean-cloogle/Cloogle#clean-documentation)
== Layout ==
Whitespace and new lines can be used to format code nicely. When tabs are used
for alignment, they are considered to be fixed to four spaces.
Tabs should be used for indentation. Spaces for alignment.
`where` clauses should not be indented.
== Exporting functions and types ===
Definition modules (.dcl) must be very specific about the modules they import
......@@ -57,10 +57,13 @@ 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:
* Explicitly import the types and classes you need for specifying the type
signatures by using the "from ... import ..." notation.
- 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.
* Only ever import an entire module with the "import ..." notation if you
really truly want to re-export the entire module.
== Implementing class instances and generic derives ==
Implementation modules can be more liberal with what they import.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment