Developers.CodingGuidelines

Coding Guidelines

These are the rules Mike used while coding Shareaza. To maintain a consistent form, new code should also follow these rules (equivalent to Artistic Style's -TCSbP):

• Tabs, not spaces
• Tab size of 4 chars
• Lots and lots of whitespace (both newlines and character spacing)
• The { and } around blocks of code have their own line, i.e.:

[code Brackets getting their own line] if ( blah ) {

   something();

} </source> AS OPPOSED TO [code Brackets not getting their own line] if ( blah ) {

   something();

} </source>

• No space between a function name and its argument list, i.e.:

<source lang="c">function( arg, arg );</source> AS OPPOSED TO <source lang="c">function ( arg, arg );</source>

• Spaces around ALL statements and MOST operators, i.e.:

<source lang="c"> for ( int a = 0 ; a < b ; a ++ )

   if ( c > d + e )

</source> AS OPPOSED TO <source lang="c"> for(int a=0;a<b;a++)

   if( c>d+e )

</source> I do tend to make an exception for some operators such as * and &, and a++ / ++a. So, basically, a really liberal use of spaces to make things extra readable. Other stuff is pretty obvious..

• Function naming uses capitals for the first letter of each word, lowercase for the rest, with words running together.
• Variables are always named with a prefix character or string identifying their type, for example "nCount" is a number and "strName" is a string and "pszName" is a pointer to a string, MS style. There are lots of other like "bsName" is a BSTR (BASIC string, usually related to automation). The "p" prefix generally means pointer to, and so "pStruct" is a pointer to some struct and "ppStruct" is a pointer to a pointer to a struct. However I often use "p" to prefix an instance of an object directly, i.e. not a pointer.. in newer projects I use "o" instead, but Shareaza predates that.
• Member variables have the Microsoft style "m_" prefix.
• I generally avoid using single character variables ala "i".
• #define'ed things are in all capitals with underscores between words, i.e. "#define MAX_VALUE 10".
• ALL classes begin with an uppercase "C", i.e. CNeighbour, CBuffer, etc.
• Different kinds of classes have different suffix conventions, like dialogs are "CXxxDlg", windows are "CXxxWnd", controls are "CXxxCtrl".
• Filenames reflect the classnames, but omit the "C" prefix. For example "CBuffer" is in "Buffer.cpp/.h". For the suffixes mentioned above like "Ctrl" and "Dlg" and "Wnd", the suffix is moved to the front of the filename and becomes a prefix, i.e. "CHelpDlg" is in "DlgHelp.cpp/.h". This results in similar classes being grouped together when looking at a list of files.