1 The class libraries are grouped together in the assemblies they belong.
3 Each directory here represents an assembly, and inside each directory we
4 divide the code based on the namespace they implement.
6 In addition, each assembly directory contains a Test directory that holds the
7 NUnit tests for that assembly.
9 We use a new build system which is described by various README files
12 The build process typically builds an assembly, but in some cases it
13 also builds special versions of the assemblies intended to be used for
16 * Missing implementation bits
18 If you implement a class and you are missing implementation bits,
19 please use the attribute [MonoTODO]. This attribute can be used
20 to programatically generate our status web pages:
25 throw new NotImplementedException ();
28 * Supporting .NET 1.2, .NET 1.1 and .NET 1.0 builds
30 The defines NET_1_1 and NET_2_0 are used to include
31 features. When NET_2_0 is defined, it also implies that the
34 To have code which is only available in an old version, use ONLY_1_0,
39 If there is a bug in your implementation tag the problem by using
40 the word "FIXME" in the code, together with a description of the
43 Do not use XXX or obscure descriptions, because otherwise people
44 will not be able to understand what you mean.
46 * Tagging Problematic specs.
48 If the documentation and the Microsoft implementation do
49 differ (you wrote a test case to prove this), I suggest that you edit
50 the file `mcs/class/doc/API-notes' so we can keep track of these problems
51 and submit our comments to ECMA or Microsoft and seek clarification.
53 Sometimes the documentation might be buggy, and sometimes the implementation
54 might be buggy. Lets try to identify and pinpoint which one
57 Sometimes the specification will be lame (consider Version.ToString (fieldCount)
58 where there is no way of knowing how many fields are available, making the API
59 not only stupid, but leading to unreliable code).
61 In those cases, use the keyword "LAMESPEC".
64 * Coding considerations and style.
66 In order to keep the code consistent, please use the following
67 conventions. From here on `good' and `bad' are used to attribute
68 things that would make the coding style match, or not match. It is not
69 a judgement call on your coding abilities, but more of a style and
70 look call. Please try to follow these guidelines to ensure prettiness.
72 Use 8 space tabs for writing your code (hopefully we can keep
73 this consistent). If you are modifying someone else's code, try
74 to keep the coding style similar.
76 Since we are using 8-space tabs, you might want to consider the Linus
77 Torvals trick to reduce code nesting. Many times in a loop, you will
78 find yourself doing a test, and if the test is true, you will nest.
79 Many times this can be changed. Example:
82 for (i = 0; i < 10; i++) {
88 This take precious space, instead write it like this:
90 for (i = 0; i < 10; i++) {
98 * Use a space before an opening parenthesis when calling
99 functions, or indexing, like this:
104 * Do not put a space after the opening parenthesis and the
107 good: method (a); array [10];
109 bad: method ( a ); array[ 10 ];
111 * Inside a code block, put the opening brace on the same line
127 * Avoid using unecessary open/close braces, vertical space
139 * When defining a method, use the C style for brace placement,
140 that means, use a new line for the brace, like this:
151 * Properties and indexers are an exception, keep the
152 brace on the same line as the property declaration.
153 Rationale: this makes it visually
154 simple to distinguish them.
171 Notice how the accessor "get" also keeps its brace on the same
174 For very small properties, you can compress things:
178 get { return value; }
182 * Use white space in expressions liberally, except in the presence
187 if (a + 5 > method (blah () + 4))
190 if (a+5>method(blah()+4))
192 * For any new files, please use a descriptive introduction, like
196 // System.Comment.cs: Handles comments in System files.
199 // Juan Perez (juan@address.com)
201 // (C) 2002 Address, Inc (http://www.address.com)
204 * If you are modyfing someone else's code, and your contribution
205 is significant, please add yourself to the Authors list.
207 * Switch statements have the case at the same indentation as the
217 * Argument names should use the camel casing for
218 identifiers, like this:
221 void Method (string myArgument)
224 void Method (string lpstrArgument)
225 void Method (string my_string)
227 * Empty methods: They should have the body of code using two
228 lines, in consistency with the rest:
236 void EmptyMethod () {}
241 * Line length: The line length for C# source code is 134 columns.
244 If your function declaration arguments go beyond
245 this point, please align your arguments to match the
246 opening brace, like this:
248 void Function (int arg, string argb,
253 When invoking functions, the rule is different, the
254 arguments are not aligned with the previous
255 argument, instead they begin at the tabbed position,
260 MethodCall ("Very long string that will force",
261 "Next argument on the 8-tab pos",
262 "Just like this one")
266 Here are a couple of examples:
270 bool Method (int argument_1, int argument_2)
272 if (argument_1 == argument_2)
273 throw new Exception (Locale.GetText ("They are equal!");
275 if (argument_1 < argument_2) {
276 if (argument_1 * 3 > 4)
283 // This sample helps keep your sanity while using 8-spaces for tabs
285 VeryLongIdentifierWhichTakesManyArguments (
286 Argument1, Argument2, Argument3,
301 void AnotherMethod ()