116 lines
3.3 KiB
Plaintext
116 lines
3.3 KiB
Plaintext
/**
|
|
\page "VCG Library Coding Guide"
|
|
\section style VCG Library Coding Guide
|
|
|
|
\subsection naming Naming Rules
|
|
|
|
<P><B><I>Class names </I></B> with first letter Uppercase and internal
|
|
uppercase to separate compound words.\n
|
|
|
|
<P><B><I>Function members</I></B> of classes follow the same rule.</P>
|
|
|
|
<P>Example:</P>
|
|
|
|
\code
|
|
Point3f
|
|
{
|
|
public:
|
|
ScalarType &V(const int i);
|
|
}
|
|
\endcode
|
|
|
|
<P><B><I>Public Variable members</I></B> has the first letter
|
|
lowercase and internal uppercase to separate compound words.</P>
|
|
|
|
<P>Example:</P>
|
|
|
|
<pre></pre>
|
|
|
|
<P><B><I>Private Variable members</I></B> has an underscore as first char and
|
|
the first letter lowercase and internal uppercase to separate compound
|
|
words.</P>
|
|
|
|
<P>Example:</P>
|
|
|
|
<pre>
|
|
Point3f
|
|
{
|
|
private:
|
|
ScalarType _v[3];
|
|
}
|
|
</pre>
|
|
|
|
<P><B><I>Class Template Arguments</I></B> all capitalized and with names
|
|
remembering where they have been defined.<br>
|
|
Class TypeDefs used for templated Class arguments or for shortness are just like Class Names,
|
|
but ending with “Type”, “Iterator”, “Pointer”, or “Container”.</P>
|
|
|
|
<P>Example:</P>
|
|
<pre>
|
|
typedef typename VertexType::CoordType CoordType;
|
|
typedef typename VertContainer::iterator VertexIterator;
|
|
|
|
</pre>
|
|
|
|
<H2 >Header Files</H2>
|
|
<P>Header filenames and folders always fully lower case. Compound names
|
|
are separated by '_'.</P>
|
|
|
|
<P>Example:</P>
|
|
|
|
<pre>
|
|
#include<vcg/space/point3.h>
|
|
</pre>
|
|
|
|
<P>Each include file must begin with the standard legal
|
|
disclamier/license intestation and report in the first line of history
|
|
the $LOG$ cvs string.</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 rely on the files included by its own
|
|
include files. Example: in vcg/space/box3.h:</P>
|
|
|
|
<pre>
|
|
#include<vcg/math/base.h> // not necessary because included by point3.h
|
|
|
|
#include<vcg/space/point3.h>
|
|
</pre>
|
|
|
|
<P>In Class definitions place all the prototypes all together before
|
|
the inline or templated implementations.</P>
|
|
|
|
<H2 >Editing Rules</H2>
|
|
|
|
<P>Tabs are equivalent to two spaces.</P>
|
|
|
|
<P>There are no strict rules for the placement of '{' or indenting.</P>
|
|
|
|
<H2 >Constructors and casting</H2>
|
|
|
|
<P>All basic classes (point3, box3 ecc) must have null
|
|
constructors. Non null constructors can be added in debug
|
|
versions.</P>
|
|
|
|
<P>Implicit casting is disallowed. Write a member Import function for
|
|
casting from different integral types and a static.<br>
|
|
Construct to build an object from different a integral type.</P>
|
|
|
|
<P>Example:</P>
|
|
|
|
<pre>
|
|
Point3f pf(1.0f,0.0f,0.0f);
|
|
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>
|
|
<P> Namespaces and files should be also documented trying to explain how the file/namespace partitioning works.
|
|
</P>
|
|
</BODY>
|
|
</HTML>
|
|
*/
|