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.
+We use a new build system which is described by various README files
+in mcs/build
+The build process typically builds an assembly, but in some cases it
+also builds special versions of the assemblies intended to be used for
+testing.
* Missing implementation bits
[MonoTODO]
int MyFunction ()
{
- throw new Exception ("Unimplemented");
+ throw new NotImplementedException ();
}
+ Ideally, write a human description of the reason why there is
+ a MonoTODO, this will be useful in the future for our
+ automated tools that can assist in developers porting their
+ code.
+
+ Do not use MonoTODO attributes for reminding yourself of
+ internal changes that must be done. Use FIXMEs or other kinds
+ of comments in the source code for that purpose, and if the
+ problem requires to be followed up on, file a bug.
+
+* Supporting .NET 1.2, .NET 1.1 and .NET 1.0 builds
+
+ The defines NET_1_1 and NET_2_0 are used to include
+ features. When NET_2_0 is defined, it also implies that the
+ NET_1_1 is defined.
+
+ To have code which is only available in an old version, use ONLY_1_0,
+ ONLY_1_1
+
* Tagging buggy code
If there is a bug in your implementation tag the problem by using
A few guidelines:
* Use a space before an opening parenthesis when calling
- functions, like this:
+ 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);
+ good: method (a); array [10];
- bad: method ( a );
+ bad: method ( a ); array[ 10 ];
* Inside a code block, put the opening brace on the same line
as the statement:
code ();
}
- * Avoid using unecessary open/close braces, vertical space
+ * Avoid using unnecessary open/close braces, vertical space
is usually limited:
good:
void Method () {
}
- * Properties are an exception, keep the brace on the same line
- as the property declaration. Rationale: this makes it visually
+ * 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:
Notice how the accessor "get" also keeps its brace on the same
line.
+ For very small properties, you can compress things:
+
+ ok:
+ int Property {
+ get { return value; }
+ set { x = value; }
+ }
+
* Use white space in expressions liberally, except in the presence
of parenthesis:
* 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':
+ ...
+ }
+
+ * Argument names should use the camel casing for
+ identifiers, like this:
+
+ good:
+ void Method (string myArgument)
+
+ bad:
+ void Method (string lpstrArgument)
+ void Method (string my_string)
+
+ * Empty methods: They should have the body of code using two
+ lines, in consistency with the rest:
+
+ good:
+ void EmptyMethod ()
+ {
+ }
+
+ bad:
+ void EmptyMethod () {}
+
+ void EmptyMethod ()
+ {}
+
+ * Line length: The line length for C# source code is 134 columns.
+
+
+ If your function declaration arguments go beyond
+ this point, please align your arguments to match the
+ opening brace, like this:
+
+ void Function (int arg, string argb,
+ int argc)
+ {
+ }
+
+ When invoking functions, the rule is different, the
+ arguments are not aligned with the previous
+ argument, instead they begin at the tabbed position,
+ like this:
+
+ void M ()
+ {
+ MethodCall ("Very long string that will force",
+ "Next argument on the 8-tab pos",
+ "Just like this one")
+
+ }
+
Here are a couple of examples:
class X : Y {
}
}
}
-
\ No newline at end of file
+
projects / mono.git / blobdiff