1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
|
The class libraries are grouped together in the assemblies they belong.
Each directory here represents an assembly, and inside each directory we
divide the code based on the namespace they implement.
In addition, each assembly directory contains a Test directory that holds the
NUnit tests for that assembly.
The nant build file for an assembly creates two versions of the dll for that
assembly. One version is a "full" dll. The full dll contains (almost) all
of the classes, regardless of how complete the classes are. The name of this
dll is the normal name you would expect, like "corlib.dll" or "System.dll".
These full dll's are created in the /mcs/class/lib directory.
The other dll which is built is a "restricted" dll. The restricted dll
omits incomplete classes that would prevent the NUnit testrunner from actually
running the tests. These restricted dll's are created in the Test directory
of their respective assembly and named with a "_res" suffix. So, for example,
the NUnit-testable dll for corlib is /mcs/class/corlib/Test/corlib_res.dll.
The final dll which is built is the one which houses the actual NUnit tests.
This dll is built from all of the classes in the Test directory and below, and
is named with a "_test" suffix. So, for example, the NUnit tests for corlib
are in /mcs/class/corlib/Test/corlib_test.dll. This dll is also linked with
the restricted dll found in the same directory.
* Missing implementation bits
If you implement a class and you are missing implementation bits,
please use the attribute [MonoTODO]. This attribute can be used
to programatically generate our status web pages:
[MonoTODO]
int MyFunction ()
{
throw new NotImplementedException ();
}
* Tagging buggy code
If there is a bug in your implementation tag the problem by using
the word "FIXME" in the code, together with a description of the
problem.
Do not use XXX or obscure descriptions, because otherwise people
will not be able to understand what you mean.
* Tagging Problematic specs.
If the documentation and the Microsoft implementation do
differ (you wrote a test case to prove this), I suggest that you edit
the file `mcs/class/doc/API-notes' so we can keep track of these problems
and submit our comments to ECMA or Microsoft and seek clarification.
Sometimes the documentation might be buggy, and sometimes the implementation
might be buggy. Lets try to identify and pinpoint which one
is the correct one.
Sometimes the specification will be lame (consider Version.ToString (fieldCount)
where there is no way of knowing how many fields are available, making the API
not only stupid, but leading to unreliable code).
In those cases, use the keyword "LAMESPEC".
* Coding considerations and style.
In order to keep the code consistent, please use the following
conventions. From here on `good' and `bad' are used to attribute
things that would make the coding style match, or not match. It is not
a judgement call on your coding abilities, but more of a style and
look call. Please try to follow these guidelines to ensure prettiness.
Use 8 space tabs for writing your code (hopefully we can keep
this consistent). If you are modifying someone else's code, try
to keep the coding style similar.
Since we are using 8-space tabs, you might want to consider the Linus
Torvals trick to reduce code nesting. Many times in a loop, you will
find yourself doing a test, and if the test is true, you will nest.
Many times this can be changed. Example:
for (i = 0; i < 10; i++) {
if (something (i)) {
do_more ();
}
}
This take precious space, instead write it like this:
for (i = 0; i < 10; i++) {
if (!something (i))
continue;
do_more ();
}
A few guidelines:
* Use a space before an opening parenthesis when calling
functions, or indexing, like this:
method (a);
b [10];
* Do not put a space after the opening parenthesis and the
closing one, ie:
good: method (a); array [10];
bad: method ( a ); array[ 10 ];
* Inside a code block, put the opening brace on the same line
as the statement:
good:
if (a) {
code ();
code ();
}
bad:
if (a)
{
code ();
code ();
}
* Avoid using unecessary open/close braces, vertical space
is usually limited:
good:
if (a)
code ();
bad:
if (a) {
code ();
}
* When defining a method, use the C style for brace placement,
that means, use a new line for the brace, like this:
good:
void Method ()
{
}
bad:
void Method () {
}
* Properties and indexers are an exception, keep the
brace on the same line as the property declaration.
Rationale: this makes it visually
simple to distinguish them.
good:
int Property {
get {
return value;
}
}
bad:
int Property
{
get {
return value;
}
}
Notice how the accessor "get" also keeps its brace on the same
line.
* Use white space in expressions liberally, except in the presence
of parenthesis:
good:
if (a + 5 > method (blah () + 4))
bad:
if (a+5>method(blah()+4))
* For any new files, please use a descriptive introduction, like
this:
//
// System.Comment.cs: Handles comments in System files.
//
// Author:
// Juan Perez (juan@address.com)
//
// (C) 2002 Address, Inc (http://www.address.com)
//
* If you are modyfing someone else's code, and your contribution
is significant, please add yourself to the Authors list.
* Switch statements have the case at the same indentation as the
switch:
switch (x) {
case 'a':
...
case 'b':
...
}
Here are a couple of examples:
class X : Y {
bool Method (int argument_1, int argument_2)
{
if (argument_1 == argument_2)
throw new Exception (Locale.GetText ("They are equal!");
if (argument_1 < argument_2) {
if (argument_1 * 3 > 4)
return true;
else
return false;
}
//
// This sample helps keep your sanity while using 8-spaces for tabs
//
VeryLongIdentifierWhichTakesManyArguments (
Argument1, Argument2, Argument3,
NestedCallHere (
MoreNested));
}
bool MyProperty {
get {
return x;
}
set {
x = value;
}
}
void AnotherMethod ()
{
if ((a + 5) != 4) {
}
while (blah) {
if (a)
continue;
b++;
}
}
}
|