Developers.CodingGuidelines: Difference between revisions

From Shareaza Wiki
Jump to navigation Jump to search
m (1 revision)
(Wiki syntax and template usage update...)
 
Line 1: Line 1:
==Coding Guidelines==
{{do not translate}}
 
== 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 [http://astyle.sourceforge.net/ Artistic Style]'s -TCSbP):
These are the rules Mike used while coding Shareaza. To maintain a consistent form, new code should also follow these rules (equivalent to [http://astyle.sourceforge.net/ Artistic Style]'s -TCSbP):


*Tabs, not spaces
* Tabs, not spaces
*Tab size of 4 chars
* Tab size of 4 chars
*Lots and lots of whitespace (both newlines and character spacing)
* Lots and lots of whitespace (both newlines and character spacing)
*The { and } around blocks of code have their own line, i.e.:
* The { and } around blocks of code have their own line, i.e.:
[code Brackets getting their own line]
if ( blah )
if ( blah )
{
{
     something();
     something();
}
}
</source>
AS OPPOSED TO
AS OPPOSED TO
[code Brackets not getting their own line]
if ( blah ) {
if ( blah ) {
     something();
     something();
}
}
</source>
 
* No space between a function name and its argument list, i.e.:
* No space between a function name and its argument list, i.e.:
<source lang="c">function( arg, arg );</source>
function( arg, arg );
AS OPPOSED TO
AS OPPOSED TO
<source lang="c">function ( arg, arg );</source>
function ( arg, arg );
*Spaces around ALL statements and MOST operators, i.e.:
 
<source lang="c">
* Spaces around ALL statements and MOST operators, i.e.:
for ( int a = 0 ; a &lt; b ; a ++ )
for ( int a = 0 ; a &lt; b ; a ++ )
    if ( c &gt; d + e )
    if ( c &gt; d + e )
</source>
AS OPPOSED TO
AS OPPOSED TO
<source lang="c">
for(int a=0;a&lt;b;a++)
for(int a=0;a&lt;b;a++)
    if( c&gt;d+e )
    if( c&gt;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.
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:
Other stuff is pretty obvious..
* Function naming uses capitals for the first letter of each word, lowercase for the rest, with words running together.
* 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.
* 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.
* Member variables have the Microsoft style "m_" prefix.
* I generally avoid using single character variables ala "i".
* I generally avoid using single character variables ala "i".
Line 43: Line 40:
* Different kinds of classes have different suffix conventions, like dialogs are "CXxxDlg", windows are "CXxxWnd", controls are "CXxxCtrl".
* 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.
* 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.
{{Navigation|Developers}}
[[Category:External Links]]

Latest revision as of 13:03, 26 October 2010

  Translation

Do not translate this page into other languages. It is either low priority, too specific or incomplete.

e

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.:
if ( blah )
{
   something();
}

AS OPPOSED TO

if ( blah ) {
   something();
}
  • No space between a function name and its argument list, i.e.:
function( arg, arg );

AS OPPOSED TO

function ( arg, arg );
  • Spaces around ALL statements and MOST operators, i.e.:
for ( int a = 0 ; a < b ; a ++ )
    if ( c > d + e )

AS OPPOSED TO

for(int a=0;a<b;a++)
    if( c>d+e )

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.



Navigation:     ShareazaWiki > Developers > Developers.CodingGuidelines