Update for style guidelines

git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@9612 626c5289-ae23-0410-ae9c-e8d60b6d4f22

Doc/Devel/engineering.html

@@ -434,14 +434,7 @@ making your changes.
 <a name="10" href="#i10">
 <h2>10. Miscellaneous Coding Guidelines</h2>
 </a>
-
+These are largely covered in the main documentation in the Extending.html file.
-<ul>
-<li> Do not use the ternary ?: operator.  It is unnecessarily error prone,
-hard for people to read, and hard to maintain code that uses it.
-[I don't agree w/ this guideline.  ?: operator can be abused
-just like everything else, but it can also be used cleanly.  In some styles of
-programming, it is the best tool for the job.  --ttn]
-</ul>
 
 <a name="11" href="#i11">
 <h2>11. CVS Tagging Conventions</h2>

Doc/Manual/Contents.html

@@ -151,7 +151,7 @@
 <li><a href="SWIG.html#SWIG_nn25">Linking to <tt>char *</tt></a>
 <li><a href="SWIG.html#SWIG_nn26">Arrays</a>
 <li><a href="SWIG.html#SWIG_readonly_variables">Creating read-only variables</a>
-<li><a href="SWIG.html#SWIG_nn28">Renaming and ignoring declarations</a>
+<li><a href="SWIG.html#SWIG_rename_ignore">Renaming and ignoring declarations</a>
 <li><a href="SWIG.html#SWIG_default_args">Default/optional arguments</a>
 <li><a href="SWIG.html#SWIG_nn30">Pointers to functions and callbacks</a>
 </ul>
@@ -1424,6 +1424,7 @@
 <li><a href="Extending.html#Extending_nn42">Examples and test cases</a>
 <li><a href="Extending.html#Extending_nn43">Documentation</a>
 <li><a href="Extending.html#Extending_prerequisites">Prerequisites for adding a new language module to the SWIG distribution</a>
+<li><a href="Extending.html#Extending_coding_style_guidelines">Coding style guidelines</a>
 </ul>
 <li><a href="Extending.html#Extending_nn44">Typemaps</a>
 <ul>

Doc/Manual/Extending.html

@@ -60,6 +60,7 @@
 <li><a href="#Extending_nn42">Examples and test cases</a>
 <li><a href="#Extending_nn43">Documentation</a>
 <li><a href="#Extending_prerequisites">Prerequisites for adding a new language module to the SWIG distribution</a>
+<li><a href="#Extending_coding_style_guidelines">Coding style guidelines</a>
 </ul>
 <li><a href="#Extending_nn44">Typemaps</a>
 <ul>
@@ -3312,6 +3313,9 @@ details being outlined earlier on.
   the language module.
   </li>
   <li>
+  Ensure your source code is formatted according to the <a href="#Extending_coding_style_guidelines">coding style guidelines</a>.
+  </li>
+  <li>
   Finally, email the SWIG developers with a patch and a demonstration of
   commitment to maintaining the language module,
   certainly in the short term and ideally long term.
@@ -3326,6 +3330,29 @@ should be added should there be an area not already covered by
 the existing tests.
 </p>
 
+<H3><a name="Extending_coding_style_guidelines"></a>33.10.14 Coding style guidelines</H3>
+
+
+<p>
+The coding guidelines for the C/C++ source code are pretty much K&amp;R C style.
+The style can be inferred from the existing code base and is
+largely dictated by the <tt>indent</tt> code beautifier tool set to K&amp;R style.
+The code can formatted using the make targets in the Source directory.
+Below is an example of how to format the emit.cxx file:
+</p>
+
+<blockquote>
+<pre>
+$ cd Source
+$ make beautify-file INDENTFILE=Modules/emit.cxx
+</pre>
+</blockquote>
+
+<p>
+Of particular note is indentation is set to 2 spaces and a tab is used instead of 8 spaces.
+The generated C/C++ code should also follow this style as close as possible. However, tabs
+should be avoided as unlike the SWIG developers, users will never have consistent tab settings.
+</p>
 
 <H2><a name="Extending_nn44"></a>33.11 Typemaps</H2>