I had a job where we had a convention of using Hungarian notation for PHP. I and others left the place bit by bit, and we never really brought it up again. We were kind of sick of it. It doesn't really work well, especially when you have a statically typed language.

Personally, I like to use 'thingList' instead of 'things' and names like 'thingMap' for map types. I don't always do this, but it works must of the time, and it's much better than 'arrPirate' for an array of Pirates.

On Saturday, 1 June 2013 at 20:42:47 UTC, D-Sturbed wrote:
> On Saturday, 1 June 2013 at 20:34:42 UTC, D-Sturbed wrote:
>> 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@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 ;)
>
> Sorry...

Yes I'm really sorry 'cause I'm realy "disturbed"...I'm kind of a troll.
You have to deal with us. Even if your superman prefears the "Template Meta Programming..."

On Tuesday, 4 June 2013 at 15:51:14 UTC, D-Sturbed wrote:
> On Saturday, 1 June 2013 at 20:42:47 UTC, D-Sturbed wrote:
>> On Saturday, 1 June 2013 at 20:34:42 UTC, D-Sturbed wrote:
>>> 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@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 ;)
>>
>> Sorry...
>
> Yes I'm really sorry 'cause I'm realy "disturbed"...I'm kind of a troll.
> You have to deal with us. Even if your superman prefears the "Template Meta Programming..."

There's even a technical desciption of asholes such as me:

Online disinhibition effect.
(http://en.wikipedia.org/wiki/Online_disinhibition_effect)

you're not a douche.

On Saturday, 1 June 2013 at 20:41:14 UTC, Namespace wrote:
> In my world, every variable or identifier name is chosen so that it is clear what it does. So I have no use for Hungarian notation.
> I think that everyone should proceed that way, then Hungarian notation is already obsolete.

+1 no need for Hungarian if code is clean.