-The class libraries are grouped together in the assemblies they belong.
+* Coding Style for the Mono C# source code.
-Each directory here represents an assembly, and inside each directory we
-divide the code based on the namespace they implement.
+* Class Libraries and Assembly Layout
-In addition, each assembly directory contains a Test directory that holds the
-NUnit tests for that assembly.
-
-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.
+ 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.
+
+ 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
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
do_more ();
}
- A few guidelines:
+* Performance and readability
+
+ It is more important to be correct than to be fast.
+
+ It is more important to be maintainable than to be fast.
+
+ Fast code that is difficult to maintain is likely going to
+ be looked down upon.
+
+* Style Guidelines
* Use a space before an opening parenthesis when calling
functions, or indexing, like this:
"Just like this one")
}
+
+ * Variable declaration indentation.
+
+ Sometimes it is convenient to indent the variables to make the code
+ look pretier, but do not add gratuitous space, try to use the minimally
+ necessary space, for example:
+
+ Good:
+
+ void Method ()
+ {
+ string b;
+ int a;
+ byte c;
+ }
+
+ Bad:
+
+ void Method ()
+ {
+ string b;
+ int a;
+ byte c;
+ }
+
+ * Braces and the `else' clause
+
+ If there are braces closing or opening next to the else clause,
+ they go on the same line as the word `else', for example:
+
+ Good:
+
+ if (..) {
+
+ } else {
+
+ }
+
+ Bad:
+
+ if (..) {
+
+ }
+ else {
+
+ }
+
+ Bad:
+
+ if (..) {
+
+ } else
+ {
+ }
+
+ Bad:
+
+ if (..) {
+
+ }
+ else
+ {
- Here are a couple of examples:
+ }
+
+* RCS and CVS tags
+
+ Some users like to use the special RCS/CVS tags in their
+ source code: $id$, $log$ and so on.
+
+ The use of these is not permitted on the Mono source code
+ repository. This metadata belongs on a ChangeLog or in the
+ SVN metadata.
+
+* File formats
+
+ Historically our repository has used a mix of line-endings,
+ this is a mistake that we are trying hard to fix.
+
+ For existing files, please make sure that you do not convert
+ the file, as that causes us to loose precious history (the
+ full file is commited).
+
+ For new files that you create, please make sure that you use
+ Subversion's support for mapping the line endings
+ automatically, after adding your file:
+
+ $ svn add file.cs
+
+ Execute this command:
+
+ $ svn propset svn:eol-style native file.cs
+
+ Which will make the file automatically receive the proper
+ treatment from that point on.
+
+ Please verify before commiting that your changes wont loose
+ history, you can do this by running:
+
+ $ svn diff
+
+ And examining the output.
+
+* Warnings
+
+ Avoid commiting code with warnings to the repository, the use
+ of #pragmas to disable warnings is strongly discouraged, but
+ can be used on unique cases. Please justify the use of the
+ warning ignore clause on a comment.
+
+ Do not commit changes to the Makefiles that removes warnings,
+ if anything warnings should be eliminated one at a time, and
+ if not possible, they must be flagged.
+
+
+* Examples:
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
projects / mono.git / blobdiff