Haha... guter Witz. Ich komm seit Jahren zu nix mehr
-----------
Ok I'll try to sum up my naming conventions.
Variable prefixes:
vec - VECTOR
ang - ANGLE
pan - PANEL*
txt - TEXT*
ent - ENTITY*
fnt - FONT*
view - VIEW*
bmap - BMAP*
par - PARTICLE*
snd - SOUND*
(note that engine objects are always pointers, so I did not use a further 'p' prefix to mark it as pointer)
c - char
f - float
i - int
l - long
v - var
s - struct
p - pointer
pp - pointer to pointer
pf - function pointer
e.g.
vTemp would be a var.
psData would be a pointer to a user defined structure
panDisplay would be a PANEL
vecTemp is a VECTOR
pvecTemp is a VECTOR*
Global variables always get a module prefix consisting of 3-10 capital letters.
<unit>_xxx: global variable which may be accessed by other units (should be avoided)
<unit>__xxx: global variable which is only used in the module wher eit was defined.
e.g.
LIST__vNumEntries: global var of the module 'LIST'. Not to be used outside the LIST module.
LIST_vReady: project global var defined int he module 'LIST'.
iParameters: local int variable. This naming may also be used for struct elements.
Function can either be global as well as local. They follow pretty much the scheme for variables above:
<unit>_xxx: interface function to other units
<unit>__xxx: module internal function
e.g.
LIST_getEntries(): interface function ready for use in other modules
LIST__process(): some internal function which must not be used in other modules
Core variable/function names (resembled by 'xxx' in the rules):
Are always CamelCase.
e.g.
vCamelCase
CAMEL_camelCaseFunction()
CAMEL__psCasedCamelCase
Example from my side:
http://firoball.de/stuff/toolbox_manual/list_8h.htmlIf you like it, feel free to use, otherwise: no problem.
If there is more interest in this, I can also sum up some of my core rules for writing readable code.
