Remove ChangeLog references from Makefile and .gitattribute
[mono.git] / mcs / CodingStyle
index 9ca84959917b39c875168e8a4dce2d382cc3bbc0..9d2deb9122f88a1b0759a16c4ba42b6c9272a885 100644 (file)
        please use the attribute [MonoTODO].  This attribute can be used
        to programatically generate our status web pages:
 
-       [MonoTODO]
+       [MonoTODO("My Function is not available on Mono")]
        int MyFunction ()
        {
                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
+       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.
 
 * Tagging buggy code
 
 
        And examining the output.
 
-* ChangeLogs
-
-       ChangeLogs are the files that we use to track the project
-       history.  ChangeLogs are found one per directory, or in small
-       projects, one per project.
-
-       The format looks like this:
-
-       2004-11-19  Raja R Harinath  <rharinath@novell.com>
-
-               * Makefile (%-profiles): Go through an intermediate
-               set of rules.  Move body to ...
-               (profiles-do--%): ... this.
-               (profiles-do--run-test): Customized rule that usefully
-               runs with 'make -j' and 'make -k'.
-               (profiles-do--all, profile-do--%--all): Orchestrate
-               the bootstrap process.
-
-               * file.cs (MainForm): Updated version.
-
-       The date, author, email address in the first line.
-
-       From that point on a list of changes in a file-by-file basis,
-       describing what changes were done.
-               
 * Warnings
 
        Avoid commiting code with warnings to the repository, the use
@@ -464,4 +434,44 @@ class X : Y {
                }
        }
 }
-       
+
+* Conditional compilation
+
+       Ideally we would not need conditional compilation, and the use
+       of #ifdef is strongly discouraged.  But due to our support for
+       old C# 1.0 compilers we have to use it in a few places.
+
+       Try to avoid negative tests that have an else clause, for
+       example:
+
+           #if !NET_2_0
+               CODE_FOR_1_0
+            #else
+               CODE_FOR_2_0
+           #endif
+
+        Instead use:
+
+           #if NET_2_0
+               CODE_FOR_2_0
+           #else
+               CODE_FOR_1_0
+            #endif
+
+       When a major feature differs across compilation targets, try
+       to factor out the code into a separate class, a helper class
+       or a separate file, and include that in your profile while
+       surrounding that helper file/class with the ifdefs to reduce
+       the amount of ifdefs in the code.
+
+       For instance, this is used for some parts of Grasshopper where
+       the code is ifdefed out, when large parts of a file would have
+       been ifdefed out, we moved the code into a MyOtherFile.jvm.cs
+
+       For 2.0 classes, this is even simpler as code can be trivially
+       factored out into 
+
+                MyHelperClass.cli.cs
+                MyHelperClass.jvm.cs
+
+       By using partial classes.
\ No newline at end of file