Suggestion for a mixed camelCase & PascalCase notation

D-Sturbed someone at somewhere.fr
Sat Jun 1 13:34:41 PDT 2013


On Saturday, 1 June 2013 at 20:18:53 UTC, Nick Sabalausky wrote:
> 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.

And your answer can be seen as an overhead from a douche, I guess 
;)



More information about the Digitalmars-d mailing list