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.
+
* Tagging buggy code
If there is a bug in your implementation tag the problem by using
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, like this:
-
- method (a);
-
- * Do not put a space after the opening parenthesis and the
- closing one, ie:
-
- good: method (a);
-
- bad: method ( a );
-
- * 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 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.
-
- 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++;
- }
- }
-}
-
\ No newline at end of file
+ conventions: http://www.mono-project.com/community/contributing/coding-guidelines/
projects / mono.git / blobdiff