Notes about Type Names and comments

This commit is contained in:
Paolo Cignoni 2004-02-24 18:16:33 +00:00
parent 547edd7427
commit 9eda1fa70c
1 changed files with 25 additions and 20 deletions

View File

@ -20,7 +20,7 @@
<BODY LANG="en-US" DIR="LTR">
<H1 >VCG Library Coding Guide</H1>
<H2 >Naming Rules</H2>
<P><B><I>Class</I></B> names with first letter Uppercase and internal
<P><B><I>Class names</I></B> with first letter Uppercase and internal
uppercase to separate compound words.</P>
<P><B><I>Function members</I></B> of classes follow the same rule.</P>
@ -58,12 +58,14 @@ words.</P>
<P><B><I>Class Template Arguments</I></B> all capitalized and with names
remembering where they have been defined.<br>
TypeDefs used for templated Class arguments just like Class Names,
but ending with &ldquo;Type&rdquo;</P>
Class TypeDefs used for templated Class arguments or for shortness are just like Class Names,
but ending with &ldquo;Type&rdquo;, &ldquo;Iterator&rdquo;, &ldquo;Pointer&rdquo;, or &ldquo;Container&rdquo;.</P>
<P>Example:</P>
<pre>
Point3f::ScalarType
typedef typename VertexType::CoordType CoordType;
typedef typename VertContainer::iterator VertexIterator;
</pre>
<H2 >Header Files</H2>
@ -80,11 +82,11 @@ are separated by '_'.</P>
disclamier/license intestation and report in the first line of history
the $LOG$ cvs string.</P>
<P>The following automatically ge\nerated history can be, from time to
time, compressed/shortened.</P>
<P>The following automatically generated history can be, from time to
time, compressed and shortened to save space.</P>
<P>Each file of the library has to include all the files that it
requires. A include file should relies on the files included by its
requires. A include file should rely on the files included by its own
include files. Example: in vcg/space/box3.h:</P>
<pre>
@ -119,5 +121,8 @@ Construct to build an object from different a integral type.</P>
Point3d pd=Point3f::Construct(pf);
pf.Import(pd);
</pre>
<H2 >Comment and documenting</H2>
<P>All the classes, algorithms and functions <B>MUST</B> be documented using Doxygen. Please add a short intro before each class explaining design choices and for non trivial classes give some short usage example. For complex classes try to group similar members under categories. Non trivial algorithms should refer the paper/book where they are explained.</P>
</BODY>
</HTML>