An attempt at making the howto look passable

svn path=/trunk/mono/; revision=4359

1 files changed, 70 insertions, 61 deletions

diff --git a/web/mono-contribution-howto b/web/mono-contribution-howto
index 4a67227b438..7a48fcd32aa 100644
--- a/web/mono-contribution-howto
+++ b/web/mono-contribution-howto
@@ -2,22 +2,22 @@
 			<Mono newbie coders start file>
 
 
-	For those who are new to Mono and are impatient to contribute with 
-code (uhh... you are brave!!) here is the document you should read. 
+	For those who are new to Mono and are impatient to contribute
+	with code (uhh... you are brave!!) here is the document you
+	should read.
 
 	
-	You will see all Mono hackers say the same (great minds have similar 
-way of thinking): First, DO WRITE TESTS!!!. In order to do that:
+	You will see all Mono hackers say the same (great minds have
+	similar way of thinking): First, DO WRITE TESTS!!!. In order
+	to do that:
 	
-	1.- Start with the NUnit Tests Guidelines.
-	    In the cvs they are located at: mcs/class/doc/NUnitGuideli...
+	<ul>
+		* Start with the NUnit Tests Guidelines.  In the cvs
+	    	  they are located at: mcs/class/doc/NUnitGuideli...
 
-	    But wait, this is a document for impatient people. So EVERYTHING 
-	    should be here. Well, it is. 
-
-
-	    Point "2" is waiting for you inside the guidelines. Hey! this is a
-	    Must Read Line by Line Text.
+		  But wait, this is a document for impatient
+	    	  people. So EVERYTHING should be here. Well, it is. 
+	</ul>
 
 -------------------- cut here --------------------
 
@@ -83,7 +83,7 @@ build and the tests will be run along with all the others.
 
 * Tips
 
--- Provide an unique error message for Assert()
+** Provide an unique error message for Assert()
 
 Include an unique message for each Assert() so that when the assert
 fails, it is trivial to locate the failing one. Otherwise, it may be
@@ -91,42 +91,44 @@ difficult to determine which part of the test is failing. A good way
 to ensure unique messages is to use something like #A01, #A02 etc.
 
     Bad:
-
+<pre>
 	AssertEquals("array match", compare[0], i1[0]);
 	AssertEquals("array match", compare[1], i1[1]);
 	AssertEquals("array match", compare[2], i1[2]);
 	AssertEquals("array match", compare[3], i1[3]);
-
+</pre>
     Good:
-
+<pre>
 	AssertEquals("#A01", compare[0], i1[0]);
 	AssertEquals("#A02", compare[1], i1[1]);
 	AssertEquals("#A03", compare[2], i1[2]);
 	AssertEquals("#A04", compare[3], i1[3]);
-
+</pre>
 Once you used such a number in an Assert(), don't change it later on -
 people might use it it identify the test in bug reports or in mailing
 lists.
 
--- Use AssertEquals() to compare things, not Assert().
+** Use AssertEquals() to compare things, not Assert().
 
 Never compare two values with Assert() - if the test fails, people
 have no idea what went wrong while AssertEquals() reports the failed
 value.
 
     Bad:
-
+<pre>
         Assert ("A01", myTicks[0] == t1.Ticks);
-
+</pre>
     Good:
-
+<pre>
         AssertEquals ("A01", myTicks[0], t1.Ticks);
+</pre>
 
--- Constructors
+** Constructors
 
 When writing your testcase, please make sure to provide a constructor
 which takes no arguments:
 
+<pre>
         public class DateTimeTest : TestCase
         {
 
@@ -141,38 +143,43 @@ which takes no arguments:
         		}
         	}
         }
+</pre>
 
--- Namespace
-
-Please keep the namespace within each test directory consistent - all
-tests which are referenced in the same AllTests.cs must be in the same
-namespace. Of course you can use subnamespaces as you like -
-especially for subdirectories of your testsuite.
+* Namespace
 
-For instance, if your AllTests.cs is in namespace "MonoTests" and you
-have a subdirectory called "System", you can put all the tests in that
-dir into namespace "MonoTests.System".
-
--- Test your test with the microsoft runtime
-
-If possible, try to run your testsuite with the Microsoft runtime on
-Windows and make sure all tests in it pass. This is especially
-important if you're writing a totally new testcase - without this
-check you can never be sure that your testcase contains no bugs ....
+	Please keep the namespace within each test directory
+	consistent - all tests which are referenced in the same
+	AllTests.cs must be in the same namespace. Of course you can
+	use subnamespaces as you like - especially for subdirectories
+	of your testsuite.
+	
+	For instance, if your AllTests.cs is in namespace "MonoTests"
+	and you have a subdirectory called "System", you can put all
+	the tests in that dir into namespace "MonoTests.System".
 
-Don't worry if you're writing your test on Linux, other people can
-test it for you on Windows.
+* Test your test with the microsoft runtime
 
-Sometimes you may discover that a test doesn't show the expected
-result when run with the Microsoft runtime - either because there is a
-bug in their runtime or something is misleading or wrong in their
-documentation. In this case, please put a detailed description of the
-problem to mcs/class/doc/API-notes and do also report it to the list -
-we'll forward this to the Microsoft people from time to time to help
-them fix their documentation and runtime.
+	If possible, try to run your testsuite with the Microsoft
+	runtime on Windows and make sure all tests in it pass. This is
+	especially important if you're writing a totally new testcase
+	- without this check you can never be sure that your testcase
+	contains no bugs ....
+	
+	Don't worry if you're writing your test on Linux, other people
+	can test it for you on Windows.
+	
+	Sometimes you may discover that a test doesn't show the
+	expected result when run with the Microsoft runtime - either
+	because there is a bug in their runtime or something is
+	misleading or wrong in their documentation. In this case,
+	please put a detailed description of the problem to
+	mcs/class/doc/API-notes and do also report it to the list -
+	we'll forward this to the Microsoft people from time to time
+	to help them fix their documentation and runtime.
 
 -------------------- cut here ------------------------
 
+<pre>
 -------------------- TemplateTest.cs begins ----------
 
 // this is a template for making NUnit tests.  Text enclosed in square
@@ -473,20 +480,22 @@ public class CollectionBaseTest : TestCase
 
 }
 ----------------------- CollectionBaseTest.cs ends --------
-
-	4.- If you use Emacs, you might want to use the .emacs file and the 
-	    package developed by Brad Merrill mailto:zbrad@cybercom.net. It 
-	    will allow you to highlight and indent in C# style in your Emacs
-	    editor. (XEmacs will still work but it'll also complain).
-
-	5.- CSharpDevelop is a GPLed IDE developed by IC#Code. Search for it
-	    at sourceforge if you are interested in it.
-
-	6.- For those who Java: "A comparison of Microsoft's C# programming
-	    language to Sun Microsystem's Java Programming language" by Dare
-	    Obasanjo is a really good (very complete) text to read. 
-
-	7.- Suggest this point and more, now I can't think of anything more.
+</pre>
+	<ul>
+		* If you use Emacs, you might want to use the .emacs file and the 
+		  package developed by Brad Merrill mailto:zbrad@cybercom.net. It 
+		  will allow you to highlight and indent in C# style in your Emacs
+		  editor. (XEmacs will still work but it'll also complain).
+
+		*  CSharpDevelop is a GPLed IDE developed by IC#Code. Search for it
+		   at sourceforge if you are interested in it.
+
+		* For those who Java: "A comparison of Microsoft's C# programming
+		  language to Sun Microsystem's Java Programming language" by Dare
+	    	  Obasanjo is a really good (very complete) text to read. 
+
+		* Suggest this point and more, now I can't think of anything more.
+	</ul>
 
 	Enjoy!!.