Wartbed:Code style

From Dark Omen Wiki

(Difference between revisions)
Jump to: navigation, search
(Re-formatted article)
Line 10: Line 10:
==Naming conventions==
==Naming conventions==
-
* All classes and functions are captialised. All class members or any global variables are initiated by lower-case.
+
<pre style="float:right; width:50%; margin-left:2em;">
-
* Genrally, CamelCase is used to separate words in identifiers. There are exceptions where appropriate and for better adherence to STL naming conventions.
+
-
* Typedef and enumeration identifiers are upper-cased. Enumeration members need not be upper-cased but are always initiated by a common word in upper case.
+
-
 
+
-
<pre>
+
template<typename T>
template<typename T>
class Regiment
class Regiment
Line 30: Line 26:
};
};
</pre>
</pre>
-
 
+
* All classes and functions are captialised. All class members or any global variables are initiated by lower-case.
 +
* Genrally, CamelCase is used to separate words in identifiers. There are exceptions where appropriate and for better adherence to STL naming conventions.
 +
* Typedef and enumeration identifiers are upper-cased. Enumeration members need not be upper-cased but are always initiated by a common word in upper case.
 +
<br clear="all">
==Calling conventions==
==Calling conventions==
Line 40: Line 39:
==Horizontal indentation==
==Horizontal indentation==
-
* All tabs are translated to space. Tab with is set to 4 spaces.
+
<pre style="float:right; width:50%;  margin-left:2em;">
-
* All brackets are set on their own lines, except where silly or better aesthetics is achieved otherwise. Brackets are set on their own lines and underneath the first character of their owning keyword. This includes classes, scopes, flow control structures and namespace declarations.
+
-
* Switch/case-structures use indented case clauses, generally with code bodies underneath the case and indented one additional step.
+
-
* Function signatures and calls are padded with one space.
+
-
* Flow control parameters (if, for, while etc) are indented one space from their keyword and use no internal padding.
+
-
 
+
-
<pre>
+
namespace wb
namespace wb
{
{
Line 63: Line 56:
}
}
</pre>
</pre>
 +
* All tabs are translated to space. Tab with is set to 4 spaces.
 +
* All brackets are set on their own lines, except where silly or better aesthetics is achieved otherwise. Brackets are set on their own lines and underneath the first character of their owning keyword. This includes classes, scopes, flow control structures and namespace declarations.
 +
* Switch/case-structures use indented case clauses, generally with code bodies underneath the case and indented one additional step.
 +
* Function signatures and calls are padded with one space.
 +
* Flow control parameters (if, for, while etc) are indented one space from their keyword and use no internal padding.
-
 
+
<br clear="all">
==Comments and vertical spacing==
==Comments and vertical spacing==
-
* Block comments are dissuaded in the main code since they interfere with temporary commenting out large blocks of code.
+
<pre style="float:right; width:60%; margin-left:2em;">
-
* Temporary commenting out of lines generally place the comment token at column 0 of the line.
+
-
* Class and function names are emphasised by a leading and following comment dash-line. Non-documentation (/** ... */ or /// comments) descriptions are placed underneath the first dash-line. While this might look a bit uncommon, it has proven to be highly useful for good code block separation and object identification.
+
-
* Separate code blocks (classes, functions) are separated by three linefeeds.
+
-
* Internal structure in code is maintained by liberal usage of blank lines.
+
-
 
+
-
<pre>
+
/*******************************************************************
/*******************************************************************
  * Source file.cpp                                                *
  * Source file.cpp                                                *
Line 112: Line 104:
}
}
</pre>
</pre>
 +
* Block comments are dissuaded in the main code since they interfere with temporary commenting out large blocks of code.
 +
* Temporary commenting out of lines generally place the comment token at column 0 of the line.
 +
* Class and function names are emphasised by a leading and following comment dash-line. Non-documentation (/** ... */ or /// comments) descriptions are placed underneath the first dash-line. While this might look a bit uncommon, it has proven to be highly useful for good code block separation and object identification.
 +
* Separate code blocks (classes, functions) are separated by three linefeeds.
 +
* Internal structure in code is maintained by liberal usage of blank lines.
 +
 +
<br clear="all">

Revision as of 22:30, 18 February 2009

Contents

Note: This page isn't something most people are interested in. I am writing and maintaining it more as a guide to myself to help me with coding consistency. Some parts of WARTBED consists of code predating this Standard and may thus deviate from it. If parties interested in assisting with WARTBED feel dissuaded for aesthetics reasons due to this Standard then remember the golden rule: "Ignore all rules to achieve the best possible result".


Naming conventions

template<typename T>
class Regiment
{
    void member() {}
    int  anotherMethod() {}   
};

typedef Regiment<int> REGIMENT;

enum ORDER
{
    ORDER_approach,
    ORDER_retreat,
};
  • All classes and functions are captialised. All class members or any global variables are initiated by lower-case.
  • Genrally, CamelCase is used to separate words in identifiers. There are exceptions where appropriate and for better adherence to STL naming conventions.
  • Typedef and enumeration identifiers are upper-cased. Enumeration members need not be upper-cased but are always initiated by a common word in upper case.


Calling conventions

  • Call-by-reference is preferred over call-by-value
  • References are preferred over pointers
  • Const is preferred over non-const
  • The "const" keyword is placed after the data type.


Horizontal indentation

namespace wb
{
    class Weapon
    {
    };

    void Function( std::string const &rStr )
    {
        AnotherFunc( rStr );

        for (unsigned i = 0; 1 < rStr.length(); ++i)
        {
        }
    }
}
  • All tabs are translated to space. Tab with is set to 4 spaces.
  • All brackets are set on their own lines, except where silly or better aesthetics is achieved otherwise. Brackets are set on their own lines and underneath the first character of their owning keyword. This includes classes, scopes, flow control structures and namespace declarations.
  • Switch/case-structures use indented case clauses, generally with code bodies underneath the case and indented one additional step.
  • Function signatures and calls are padded with one space.
  • Flow control parameters (if, for, while etc) are indented one space from their keyword and use no internal padding.


Comments and vertical spacing

/*******************************************************************
 * Source file.cpp                                                 *
 * Copyright notice and documentation                              *
 *                                                                 *
 *******************************************************************/

namespace wb
{
//------------------------------------------------------------------
    class Weapon
//------------------------------------------------------------------
    {
    };



//------------------------------------------------------------------
// SpecialWeapon is a specialisation of Weapon. It adds 
// many special capabilities over Weapon.
//
    class SpecialWeapon
//------------------------------------------------------------------
    {
    };



//------------------------------------------------------------------
    void Function( std::string const &rStr )
//------------------------------------------------------------------
    {
        AnotherFunc( rStr );

        for (unsigned i = 0; 1 < rStr.length(); ++i)
        {
        }
    }
}
  • Block comments are dissuaded in the main code since they interfere with temporary commenting out large blocks of code.
  • Temporary commenting out of lines generally place the comment token at column 0 of the line.
  • Class and function names are emphasised by a leading and following comment dash-line. Non-documentation (/** ... */ or /// comments) descriptions are placed underneath the first dash-line. While this might look a bit uncommon, it has proven to be highly useful for good code block separation and object identification.
  • Separate code blocks (classes, functions) are separated by three linefeeds.
  • Internal structure in code is maintained by liberal usage of blank lines.


Personal tools
communication