[xbuild] Don't report Imports ignored because of false conditions.

[mono.git] / mcs / CodingStyle

diff --git a/mcs/CodingStyle b/mcs/CodingStyle
index 9ca84959917b39c875168e8a4dce2d382cc3bbc0..aa78389f7b7d05d136764df67ef9e87fbc554fc5 100644 (file)
--- a/mcs/CodingStyle
+++ b/mcs/CodingStyle
@@ -25,12 +25,16 @@
        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 ();
        }
 
+       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.
+
 * 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
@@ -404,6 +408,11 @@
 
        From that point on a list of changes in a file-by-file basis,
        describing what changes were done.
+
+       This information must be cut and pasted into your commit
+       message, so the information ends up in two places: in the
+       subversion repository metadata and also on the source code
+       distirbution (which does not have the Subversion metadata).
                
 * Warnings
 
@@ -464,4 +473,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