Difference between revisions of "Coding style"

From CodeBlocks
Jump to: navigation, search
m (Commenting: use list)
Line 95: Line 95:
 
== Commenting ==
 
== Commenting ==
  
All three types of comments are used in Code::Blocks. C++ style ('//'), C style ('/* */'), and the Doxygen style ('/** */').
+
* All three types of comments are used in Code::Blocks. C++ style ('//'), C style ('/* */'), and the Doxygen style ('/** */').
 
+
* The C++ style is used for just about everything. Use this style to describe what your code does.
The C++ style is used for just about everything. Use this style to describe what your code does.
+
* The C style is used only for very long comments (paragraphs), or for a license or description at the top of a C++ file.
 
+
* The Doxygen style is used for documenting functions only. These functions would be public, and protected class functions, and global helper functions.
The C style is used only for very long comments (paragraphs), or for a license or description at the top of a C++ file.
+
* Comments should clearly describe what the code does. Comments should be concise, but coherent.
 
+
The Doxygen style is used for documenting functions only. These functions would be public, and protected class functions, and global helper functions.
+
 
+
Comments should clearly describe what the code does. Comments should be concise, but coherent.
+

Revision as of 10:40, 1 September 2006

The following are guidelines for the code formatting to use in Code::Blocks source code. Anyone writing code or a patch for Code::Blocks, is required to follow these.

Coding style

The general coding style is the ANSI one:

Example:

namespace FooSpace
{
    int Foo()
    {
        if (isBar)
        {
            Bar();
            return 1;
        }
        else
            return 0;
    }
}


Variables naming

Class names do not start with 'C' (as in CObject, CWindow, etc). Only abstract base classes (interfaces) should start with 'I'. But they all have to start with a capital letter.

Class member variables should start with m_. If the variable is a pointer, use m_p as a prefix. Following the prefix is the variable's name. Use descriptive names and use capital letters at the start of each word (the first too). So a fictious variable holding a value for position would be named as m_ValueForPosition.

Non-class member variables should not start with a capital letter.

Function names should always start with a capital letter.

Examples:

// Good
int aLocalVar;
int m_SomeInt;
void* m_pSomePointer;
bool SomeFunc();

// Bad
int SomeInt; // either no m_ prefix if it's a class variable, or capital first letter if it's a local variable
int m_someInt; // no capital letter 'S'
void* m_SomePointer; // no m_p prefix
bool someFunc(); // function with non-capital first letter


Variables declaration

One variable declared each time on a different line. For pointer/reference variables, the '*' or '&' is part of the type.

Examples:

// Good
int& someInt;
void* pPtr;

// Bad
int &someInt; // & not after type
void* pPtr, pSomeOther; // multiple declarations in one line

Spacing

Prefer spaces over tabs. If you want to use tabs you won't be prosecuted (!) but please use a tab size of 4 spaces.
Code indentation should be 4 spaces.
In class declarations, the keywords public:, protected:, and private: should be indented. The same goes for all the class members.

Examples:

// Good
class AClass
{
    public:
        AClass(){ ... }
    protected:
        int m_Member;
};

// Bad
class AClass
{
public:
    AClass(){ ... }
protected:
    int m_Member;
};

Commenting

  • All three types of comments are used in Code::Blocks. C++ style ('//'), C style ('/* */'), and the Doxygen style ('/** */').
  • The C++ style is used for just about everything. Use this style to describe what your code does.
  • The C style is used only for very long comments (paragraphs), or for a license or description at the top of a C++ file.
  • The Doxygen style is used for documenting functions only. These functions would be public, and protected class functions, and global helper functions.
  • Comments should clearly describe what the code does. Comments should be concise, but coherent.