Commit 701b4792 authored by Bas Lijnse's avatar Bas Lijnse

Added Readme, standards description and updated the API description to include...

Added Readme, standards description and updated the API description to include parentless subhierarchies

git-svn-id: https://svn.cs.ru.nl/repos/clean-platform/trunk@2 2afc29ad-3112-4e41-907a-9359c7e6e986
parent c0009d06
......@@ -9,6 +9,7 @@ Data.Maybe
Data.Set
Data.Queue
Database
Database.SQL
Database.SQL.MySQL
Database.SQL.PostgreSQL
......@@ -17,6 +18,7 @@ Database.SQL.SQLite
Gui
Gui.ObjectIO
Internet
Internet.Email
Internet.Http
Internet.Http.Cgi
......@@ -24,6 +26,7 @@ Internet.Http.HttpServer
Math
Network
Network.Tcp
Network.Udp
......@@ -36,6 +39,7 @@ System.OS
System.Process
System.Time
Test
Test.Gast
Text
......
=== Clean Platform ===
The Clean Platform is a general purpose collection of libraries to supplement the Clean Standard Environment.
To increase maintainability and readability, these libraries follow a strict coding style guideline.
This guideline can be found in the file STANDARDS.txt and on the Clean Wiki. A listing of the conceived
API the Clean Platform will provide can be found in the file API.txt
More information about this project can be found on the Clean Wiki:
http://wiki.clean.cs.ru.nl/Clean_platform
The libraries are provided under the same license as the Clean System. Details can be found at:
http://clean.cs.ru.nl/Download/License_Conditions/license_conditions.html
The following guidelines should be adhered to when developing libraries for
the Clean Platform library collection.
== 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.
The constructors of a type should also start with a capital.
== 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.
== 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.
== 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.
== 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.
== Whitespace ==
Whitespace may be used to format functions. When tabs are used for alignment, they are considered
to be four spaces wide.
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