Developers.CodingGuidelines: Difference between revisions
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.: | ||
if ( blah ) | |||
if ( blah ) | { | ||
{ | |||
something(); | something(); | ||
} | } | ||
AS OPPOSED TO | AS OPPOSED TO | ||
if ( blah ) { | |||
if ( blah ) { | |||
something(); | something(); | ||
} | } | ||
* No space between a function name and its argument list, i.e.: | * No space between a function name and its argument list, i.e.: | ||
function( arg, arg ); | |||
AS OPPOSED TO | AS OPPOSED TO | ||
function ( arg, arg ); | |||
*Spaces around ALL statements and MOST operators, i.e.: | |||
* Spaces around ALL statements and MOST operators, i.e.: | |||
for ( int a = 0 ; a < b ; a ++ ) | for ( int a = 0 ; a < b ; a ++ ) | ||
if ( c > d + e ) | |||
AS OPPOSED TO | AS OPPOSED TO | ||
for(int a=0;a<b;a++) | |||
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. | |||
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