123 lines
2.9 KiB
Plaintext
123 lines
2.9 KiB
Plaintext
Coding Conventions for AppleWin
|
|
===============================
|
|
|
|
History:
|
|
v2 - 16-Feb-2006 (TC)
|
|
. Updated after discussion with M.Pohoreski
|
|
v1 - 04-Feb-2006 (TC)
|
|
. First draft
|
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
Introduction:
|
|
-------------
|
|
|
|
This doc defines a very simple set of coding guidelines to be used for AppleWin.
|
|
This ensures consistency & readability throughout the project, when worked on
|
|
by multiple developers.
|
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
1) Project files:
|
|
|
|
1.1: Each module to have corresponding header
|
|
EG. Debug.cpp has a corresponding Debug.h
|
|
This is for shared vars, enums, structs, classes, etc.
|
|
|
|
1.2: AppleWin.h to only be used as per 1.1
|
|
|
|
1.3: Common.h to be used for any common definitions
|
|
EG. const/enum/struct
|
|
Obviously not for global funcs or vars.
|
|
|
|
1.4: PCH (StdAfx.h)
|
|
Could ditch this.
|
|
Does this gain anything for such a simple project?
|
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
2) Coding Style:
|
|
|
|
2.1: Naming
|
|
The following simplied Hungarian style must be used:
|
|
|
|
Prefixes:
|
|
a : array
|
|
b : bool
|
|
e : enum variable
|
|
g_ : global
|
|
h : handle
|
|
i : iterator (eg. UINT, STL-iterator)
|
|
m : STL map
|
|
m_ : member
|
|
n : int
|
|
p : pointer
|
|
r : reference
|
|
s : string
|
|
sg_p : singleton (could also use 'sgp' - to be reviewed)
|
|
u : unsigned int
|
|
v : STL vector
|
|
|
|
Tags:
|
|
_e : named enum definitions
|
|
_t : struct/typedef
|
|
|
|
Legacy:
|
|
dw : DWORD [legacy: existing 'dw' to be replaced with 'u' prefix]
|
|
sz : string (null-terminated) [legacy:
|
|
|
|
EG:
|
|
enum MODE_e {MODE1, MODE2, MODE2};
|
|
MODE_e eMode;
|
|
|
|
struct PAIR_t
|
|
{
|
|
UINT uA;
|
|
UINT uB;
|
|
};
|
|
|
|
Simple loop counters (i,j,k) don't need to adhere to this style.
|
|
|
|
Don't go Hungarian-mad (you might argue that we already have :)
|
|
. an array of any type can just be prefixed with 'a'. Eg. Array of bools:
|
|
bool aFlags[NUM_FLAGS];
|
|
. a pointer to any type can just be prefixed with 'p'. Eg. Pointer to array of bools:
|
|
bool* pFlags;
|
|
|
|
Naming for parameters that are being modified (eg. OUT):
|
|
It is recommended (but not mandatory) to use a suffix of OUT or '_', eg:
|
|
bool Find(int* pFoundOUT);
|
|
bool Find(int* pFound_);
|
|
|
|
|
|
2.2: Matching braces
|
|
These should be have same indentation, unless the braces fit neatly on one line.
|
|
EG:
|
|
for (int i=0; i<10; i++)
|
|
{
|
|
// Some code
|
|
}
|
|
|
|
2.3: Scope of module vars/funcs
|
|
If module vars/funcs aren't wrapped in a class, then declare as static if not global.
|
|
|
|
2.4: const/enum favoured over #define
|
|
Try to use const/enum instead of #define
|
|
|
|
2.4: Use of bool over BOOL
|
|
Always use bool instead of BOOL
|
|
|
|
2.5: File header
|
|
GPL header, followed by description of module & author.
|
|
|
|
2.6: Indentation
|
|
Tabs favoured over spaces.
|
|
|
|
2.7: Expression to be well spaced and parenthesised
|
|
It is recommended (but not mandatory):
|
|
. to have/use explicit parenthesis
|
|
. to have spaces between operators
|
|
|
|
Eg:
|
|
. Prefer: z = ((a + b) + 1) instead of: z=((a+b)+1)
|