mcs/class/README

   1 The class libraries are grouped together in the assemblies they belong.
   2
   3 Each directory here represents an assembly, and inside each directory we
   4 divide the code based on the namespace they implement.
   5
   6 In addition, each assembly directory contains a Test directory that holds the
   7 NUnit tests for that assembly.
   8
   9 We use a new build system which is described by various README files
  10 in mcs/build
  11
  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
  14 testing.
  15
  16 * Missing implementation bits
  17
  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:
  21
  22         [MonoTODO]
  23         int MyFunction ()
  24         {
  25                 throw new NotImplementedException ();
  26         }
  27
  28         Ideally, write a human description of the reason why there is
  29         a MonoTODO, this will be useful in the future for our
  30         automated tools that can assist in developers porting their
  31         code.
  32
  33         Do not use MonoTODO attributes for reminding yourself of
  34         internal changes that must be done. Use FIXMEs or other kinds
  35         of comments in the source code for that purpose, and if the
  36         problem requires to be followed up on, file a bug.
  37
  38 * Tagging buggy code
  39
  40         If there is a bug in your implementation tag the problem by using
  41         the word "FIXME" in the code, together with a description of the
  42         problem.
  43
  44         Do not use XXX or obscure descriptions, because otherwise people
  45         will not be able to understand what you mean.
  46
  47 * Tagging Problematic specs.
  48
  49         If the documentation and the Microsoft implementation do
  50         differ (you wrote a test case to prove this), I suggest that you edit
  51         the file `mcs/class/doc/API-notes' so we can keep track of these problems
  52         and submit our comments to ECMA or Microsoft and seek clarification.
  53
  54         Sometimes the documentation might be buggy, and sometimes the implementation
  55         might be buggy.  Lets try to identify and pinpoint which one
  56         is the correct one.
  57
  58         Sometimes the specification will be lame (consider Version.ToString (fieldCount)
  59         where there is no way of knowing how many fields are available, making the API
  60         not only stupid, but leading to unreliable code).
  61
  62         In those cases, use the keyword "LAMESPEC".
  63
  64 * Coding considerations and style.
  65
  66         In order to keep the code consistent, please use the following
  67         conventions: http://www.mono-project.com/community/contributing/coding-guidelines/