Mercurial > projects > mde

comparison codeDoc/policies.txt @ 174:3d58adc17d20

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Temporary commit to allow backup
author Diggory Hardy <diggory.hardy@gmail.com>
date Mon, 31 Aug 2009 13:54:23 +0200
parents 24d77c52243f
children
comparison
equal deleted inserted replaced
173:a1ba9157510e 174:3d58adc17d20
34 34
35 3 Package design principle 35 3 Package design principle
36 36
37 4 Initialisation / cleanup 37 4 Initialisation / cleanup
38 38
39 5 Testing 39 5 Callbacks
40 40
41 6 Logging 41 6 Testing
42 42
43 7 Exceptions 43 7 Logging
44 44
45 8 Translating strings 45 8 Exceptions
46 46
47 9 Floating point types 47 9 Translating strings
48
49 10 Floating point types
48 50
49 51
50 52
51 53
52 --- Coding conventions --- 54 --- Coding conventions ---
99 101
100 static [~]this(): Use of static CTORs/DTORs should be limited to very small operations which can definitely be run safely at this stage. 102 static [~]this(): Use of static CTORs/DTORs should be limited to very small operations which can definitely be run safely at this stage.
101 103
102 104
103 105
106 --- Callbacks ---
107 I suggest making callbacks called by external objects public, so that invariants are called.
108
109
110
104 --- Testing --- 111 --- Testing ---
105 Testing should, as far as reasonably possible, be done by unittests, defined either in the appropriate module or another module. Any modules containing unittests must be imported by test.mdeTest. 112 Testing should, as far as reasonably possible, be done by unittests, defined either in the appropriate module or another module. Any modules containing unittests must be imported by test.mdeTest.
106 113
107 Unittests must be wrapped in "debug(mdeUnitTest)" statements. (These may also be used to wrap imports and "static this()" only needed by the unittest.) 114 Unittests must be wrapped in "debug(mdeUnitTest)" statements. (These may also be used to wrap imports and "static this()" only needed by the unittest.)
108 115
136 143
137 144
138 --- Exceptions --- 145 --- Exceptions ---
139 Exceptions should only be used for errors (see comment on log levels above). Thus when an exception is caught, by definition an error occured. 146 Exceptions should only be used for errors (see comment on log levels above). Thus when an exception is caught, by definition an error occured.
140 147
141 Thrown exceptions should, where documented, be documented via the logger. 148 Caught exceptions should be documented via the logger. TODO: work out the best way of incorporating a stack trace. Then lots of specific exception types and messages aren't necessary.
142 149
143 Thrown exceptions should use an exception class specific to at least the package involved to enable specific catching of errors. Exception classes should be defined within a module exception.d in the package directory. Exception classes should generally follow the conventions within mde/exception.d to aid in providing reasonable error messages. 150 Thrown exceptions should use an exception class specific to at least the package involved to enable specific catching of errors. Exception classes should be defined within a module exception.d in the package directory. Exception classes should generally follow the conventions within mde/exception.d to aid in providing reasonable error messages.
144 151
145 152
146 153