AppleWin/docs/CodingConventions.txt

131 lines
3.1 KiB
Plaintext
Raw Normal View History

2006-02-22 14:34:40 +00:00
Coding Conventions for AppleWin
===============================
History:
2020-11-14 16:44:12 +00:00
v3 - 14-Nov-2020 (TC)
. #868: Reduced Hungarian notation
2006-02-22 14:34:40 +00:00
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.
2006-02-22 14:34:40 +00:00
-------------------------------------------------------------------------------
2) Coding Style:
2.1: Naming
2020-11-14 16:44:12 +00:00
For functions use upper camel case.
For variables use lower camel case.
And if applicable, the following simplied prefix (Hungarian) style must be used:
2006-02-22 14:34:40 +00:00
Prefixes:
2020-11-14 16:44:12 +00:00
g_ : global
m_ : member
p : pointer
Tags:
_e : named enum definitions
_t : struct/typedef
Legacy:
dw : DWORD
sz : string (null-terminated)
2006-02-22 14:34:40 +00:00
a : array
b : bool
e : enum variable
h : handle
i : iterator (eg. UINT, STL-iterator)
m : STL map
n : int
r : reference
s : string
2020-11-14 16:44:12 +00:00
sg_p : singleton
2006-02-22 14:34:40 +00:00
u : unsigned int
v : STL vector
EG:
enum MODE_e {MODE1, MODE2, MODE2};
2020-11-14 16:44:12 +00:00
MODE_e mode;
2006-02-22 14:34:40 +00:00
struct PAIR_t
{
2020-11-14 16:44:12 +00:00
UINT a;
UINT b;
2006-02-22 14:34:40 +00:00
};
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
2006-02-23 19:21:36 +00:00
GPL header, followed by description of module & author.
2006-02-22 14:34:40 +00:00
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)
2020-11-14 16:44:12 +00:00
2.8: For consistency, adopt the coding convention of any module (or function) you are modifying.