Home My Page Projects Code Snippets Project Openings diderot
Summary Activity Tracker Tasks SCM

SCM Repository

[diderot] View of /branches/vis15/doc/CODING-STYLE
ViewVC logotype

View of /branches/vis15/doc/CODING-STYLE

Parent Directory Parent Directory | Revision Log Revision Log

Revision 5577 - (download) (annotate)
Mon Jun 4 21:39:40 2018 UTC (3 years, 11 months ago) by jhr
File size: 2685 byte(s)
  adding CODING-STYLE documentation
We have attempted to follow a number of coding conventions to keep the
style of the code consistent.


We use all lower-case with "-" to separate words in a filename.  We
typically put one SML module/signature per file, but occasionally include
both a named signature and module in the same file.  We use a "-fn" suffix
for files containing functors and a "-sig" siffix for files containing
signatures.  Here are some examples

	simple.sml		contains structure Simple
	ssa-sig.sml		contains signature SSA
	ssa-fn.sml		contains functor SSAFn

Some files are generated by the configure script.  For these, we follow the
convention of "_suffix.in" as their suffix.  For example,

	run-dnorm_sml.in	produces run-dnorm.sml

Orthographic conventions
We largely follow the orthographic conventions specified for SML Basis (and used
by the SML/NJ Library).

	1) Alphanumeric value identifiers are in mixed-case, with a leading
	   lower-case letter.

	2) Type identifiers are all lowercase, with words separated by "_".

	3) Signature identifiers are all upper case, with words separated by "_".

	4) Structure and functor identifiers are in mixed-case, with the initial
	   letters of words capitalized.

	5) Alphanumeric datatype constructors follow either the signature
	   convention (3) or the structure convention (4).


The basic unit of indentation is two spaces.  We indent indent the 'val' and
'fun' definitions of a 'let' expression at the same level as the 'in' and 'end'.
	val x = ...

If there is room, we usually put the 'let' on the same line as its parent.  E.g.,

	fun f x = let
              val y = ...


	if (x < 0)
	  then let
	    val y = ...


Each module should have a header comment that identifies the name of the file
and includes the copyright notice.  In an ideal world, the header comment will
also include information about what the code in the file does (but not how it does

Types and functions is signatures should also be commented.


Functions and data constructors that take multiple arguments of the same type (and
where the order is not obvious) should use a labeled record as their argument.

For case expressions, we "terminate" them with an "(* end case *)" comment.  E.g.,

	case e
	 of [] => ...
	  | x::xs => ...
	(* end case *)

ViewVC Help
Powered by ViewVC 1.0.0