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

SCM Repository

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

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

Parent Directory Parent Directory | Revision Log Revision Log


Revision 5577 - (view) (download)

1 : jhr 5577 We have attempted to follow a number of coding conventions to keep the
2 :     style of the code consistent.
3 :    
4 :     ========================================
5 :     Files
6 :     ==========
7 :    
8 :     We use all lower-case with "-" to separate words in a filename. We
9 :     typically put one SML module/signature per file, but occasionally include
10 :     both a named signature and module in the same file. We use a "-fn" suffix
11 :     for files containing functors and a "-sig" siffix for files containing
12 :     signatures. Here are some examples
13 :    
14 :     simple.sml contains structure Simple
15 :     ssa-sig.sml contains signature SSA
16 :     ssa-fn.sml contains functor SSAFn
17 :    
18 :     Some files are generated by the configure script. For these, we follow the
19 :     convention of "_suffix.in" as their suffix. For example,
20 :    
21 :     run-dnorm_sml.in produces run-dnorm.sml
22 :    
23 :    
24 :     ========================================
25 :     Orthographic conventions
26 :     ==========
27 :     We largely follow the orthographic conventions specified for SML Basis (and used
28 :     by the SML/NJ Library).
29 :    
30 :     1) Alphanumeric value identifiers are in mixed-case, with a leading
31 :     lower-case letter.
32 :    
33 :     2) Type identifiers are all lowercase, with words separated by "_".
34 :    
35 :     3) Signature identifiers are all upper case, with words separated by "_".
36 :    
37 :     4) Structure and functor identifiers are in mixed-case, with the initial
38 :     letters of words capitalized.
39 :    
40 :     5) Alphanumeric datatype constructors follow either the signature
41 :     convention (3) or the structure convention (4).
42 :    
43 :    
44 :     ========================================
45 :     Indentation
46 :     ==========
47 :    
48 :     The basic unit of indentation is two spaces. We indent indent the 'val' and
49 :     'fun' definitions of a 'let' expression at the same level as the 'in' and 'end'.
50 :     E.g.,
51 :     let
52 :     val x = ...
53 :     in
54 :     ...
55 :     end
56 :    
57 :     If there is room, we usually put the 'let' on the same line as its parent. E.g.,
58 :    
59 :     fun f x = let
60 :     val y = ...
61 :     in
62 :     ...
63 :     end
64 :    
65 :     or
66 :    
67 :     if (x < 0)
68 :     then let
69 :     val y = ...
70 :     in
71 :     ...
72 :     end
73 :    
74 :    
75 :     ========================================
76 :     Comments
77 :     ==========
78 :    
79 :     Each module should have a header comment that identifies the name of the file
80 :     and includes the copyright notice. In an ideal world, the header comment will
81 :     also include information about what the code in the file does (but not how it does
82 :     it).
83 :    
84 :     Types and functions is signatures should also be commented.
85 :    
86 :     ========================================
87 :     Miscellany
88 :     ==========
89 :    
90 :     Functions and data constructors that take multiple arguments of the same type (and
91 :     where the order is not obvious) should use a labeled record as their argument.
92 :    
93 :     For case expressions, we "terminate" them with an "(* end case *)" comment. E.g.,
94 :    
95 :     case e
96 :     of [] => ...
97 :     | x::xs => ...
98 :     (* end case *)

root@smlnj-gforge.cs.uchicago.edu
ViewVC Help
Powered by ViewVC 1.0.0