jyapayne/swig
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Update for style guidelines

Browse source 
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@9612 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
William S Fulton 2006-12-09 08:39:22 +00:00
commit 433eaef955
3 changed files with 30 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

9
Doc/Devel/engineering.html
View file

@ -434,14 +434,7 @@ making your changes.
<a name="10" href="#i10">
<h2>10. Miscellaneous Coding Guidelines</h2>
</a>
<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>
These are largely covered in the main documentation in the Extending.html file.
<a name="11" href="#i11">
<h2>11. CVS Tagging Conventions</h2>

3
Doc/Manual/Contents.html
View file

@ -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>

27
Doc/Manual/Extending.html
View file

@ -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>