Am 01.06.2013 21:58, schrieb D-Sturbed:
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.
Lets not keep Hungarian notation alive, now that even Microsoft
recognizes on their documentation that is has an error to come up with
it and recommends to keep on using it only for legacy code.
--
Paulo
