X-Git-Url: http://wien.tomnetworks.com/gitweb/?a=blobdiff_plain;f=mcs%2Fclass%2FREADME;h=fbb7a68a101acb589ddfb362bfc05c1c2d133490;hb=8292c900bda493df6ae7f046b183495dcd08064c;hp=9e0a280b865fab1708226be7a6fd09e5eab6fa3d;hpb=f00566a71f01320f5cac5e7dd80f3d3705d8b2d0;p=mono.git diff --git a/mcs/class/README b/mcs/class/README index 9e0a280b865..fbb7a68a101 100644 --- a/mcs/class/README +++ b/mcs/class/README @@ -6,24 +6,12 @@ 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. +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 @@ -37,6 +25,15 @@ the restricted dll found in the same directory. throw new NotImplementedException (); } +* 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 @@ -174,6 +171,14 @@ the restricted dll found in the same directory. 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: @@ -209,6 +214,55 @@ the restricted dll found in the same directory. ... } + * 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 { @@ -256,4 +310,4 @@ class X : Y { } } } - \ No newline at end of file +