mirror of
https://github.com/AppleWin/AppleWin.git
synced 2024-12-29 08:30:04 +00:00
131 lines
3.1 KiB
Plaintext
131 lines
3.1 KiB
Plaintext
Coding Conventions for AppleWin
|
|
===============================
|
|
|
|
History:
|
|
v3 - 14-Nov-2020 (TC)
|
|
. #868: Reduced Hungarian notation
|
|
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: At the start of each header file it must contain: #pragma once
|
|
|
|
1.5: Each module (.cpp) to include stdafx.h, and then immediately after include
|
|
the header file for that module.
|
|
EG. For Debug.cpp:
|
|
#include "stdafx.h"
|
|
#include "Debug."
|
|
|
|
This ensures that this header file can be included in any order in another module,
|
|
and therefore by extension all header files can be included in any order.
|
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
2) Coding Style:
|
|
|
|
2.1: Naming
|
|
For functions use upper camel case.
|
|
|
|
For variables use lower camel case.
|
|
And if applicable, the following simplied prefix (Hungarian) style must be used:
|
|
|
|
Prefixes:
|
|
g_ : global
|
|
m_ : member
|
|
p : pointer
|
|
|
|
Tags:
|
|
_e : named enum definitions
|
|
_t : struct/typedef
|
|
|
|
Legacy:
|
|
dw : DWORD
|
|
sz : string (null-terminated)
|
|
a : array
|
|
b : bool
|
|
e : enum variable
|
|
h : handle
|
|
i : iterator (eg. UINT, STL-iterator)
|
|
m : STL map
|
|
n : int
|
|
r : reference
|
|
s : string
|
|
sg_p : singleton
|
|
u : unsigned int
|
|
v : STL vector
|
|
|
|
EG:
|
|
enum MODE_e {MODE1, MODE2, MODE2};
|
|
MODE_e mode;
|
|
|
|
struct PAIR_t
|
|
{
|
|
UINT a;
|
|
UINT b;
|
|
};
|
|
|
|
Simple loop counters (i,j,k) don't need to adhere to this style.
|
|
|
|
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)
|
|
|
|
2.8: For consistency, adopt the coding convention of any module (or function) you are modifying.
|