Hello, I know that everybody will hate that, as most of the
people coming to D are also coming from the C world, but, anyway
I suggest this data naming convention:
class cMyClass
struct sMyStruct
template tMyTmp
parameter aParam ( + exception: someParams to denote arrays)
local lVolatileStuff (local: ESP/RSP stuffs)
interface iContextualMethods
pointer pMyClass
field fMyField
enum eMyEnum (as type only: private eMyEnum fMyEnum)
delegate dMyPrototype
stream Str (aStr,lStr,...)
void* Ptr (aPtr,lPtr,...)
data Dt (aDt,lDt,...)
camelcase with technical identifier as first letter.
a-f-l being mandatory to avoid name conflicts in the
implementation,
as in a method you'll usually have parameters, fields and local
data.
advantages:
- code completion: you can target what you want, usefull when you
are not an expert of an API/SDK: you basically know its an enum,
you don't remember the name, you type "e", you scroll a bit, you
have it.
- D compliance: this respects the camelcase convention with a
little touch of the pascal naming conv.
- it avoid confusion in the implementation: you can have a
aStuff(param) temporarly copied to a lStuff(local data) in order
to set a fStuff(protected/private field)...
disadvantages/problems:
- template classes: leads to some declarations such as
cTemplatizedClass!int, while we would expect tSomething before a
"!". "ct" (standing for ClassTemplate) can be used in this case.
- the small case "l" is know for leading to some confusion with
"1" with some particular fonts.
Give me your mind `bout this
D-Sturbed.
