Suggestion for a mixed camelCase & PascalCase notation

[Nick Sabalausky]

On Sat, 01 Jun 2013 21:58:27 +0200
"D-Sturbed" <someone at somewhere.fr> wrote:

> 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.

That's basically a variation of hungarian notation, which has been
mostly disappearing for good reasons: While it's hugely useful under
weak-typing, weak-typing has (outside of asm) been going away (also
for good reasons). Under strong typing (and under modern editors - let
alone fancy IDEs) hungarian notation (and its variations) provides
little to no benefit and creates programmer overhead.