Developers.CodingGuidelines: Difference between revisions

From Shareaza Wiki
Jump to navigation Jump to search
(Importing page from Tikiwiki)
 
(Wiki syntax and template usage update...)
 
(One intermediate revision by one other user not shown)
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