diff options
Diffstat (limited to 'mcs/class/README')
| -rw-r--r-- | mcs/class/README | 277 |
1 files changed, 0 insertions, 277 deletions
diff --git a/mcs/class/README b/mcs/class/README deleted file mode 100644 index 97382f10b20..00000000000 --- a/mcs/class/README +++ /dev/null @@ -1,277 +0,0 @@ -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. - - 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: - - 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': - ... - } - - * 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) - - 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 |