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.

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.

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 ;)

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.

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

On Saturday, June 01, 2013 21:58:27 D-Sturbed 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:

This is essentially hungarian notation, which has widely been determined to be bad practice and which our style guide specifically calls out _against_:

http://dlang.org/dstyle.html

Marking a variable with something about what it's for makes sense. Marking it with something about its type is counter-productive.

Regardless, I really don't think that we're going to change our naming conventions at this point. Doing so would either break a lot of code or result in all of our new stuff having different naming conventions from our old stuff, and we don't want to do either.

- Jonathan M Davis

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

On Saturday, June 01, 2013 23:47:29 Paulo Pinto wrote:
> 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.

The sad thing is that we got hungarian notation due to a misunderstanding. The original idea was actually quite good. This article explains what happened as well as the original idea (which _is_ worth using):

http://www.joelonsoftware.com/articles/Wrong.html

- Jonathan M Davis

On Saturday, 1 June 2013 at 22:16:49 UTC, Jonathan M Davis wrote:
> The sad thing is that we got hungarian notation due to a misunderstanding. The
> original idea was actually quite good. This article explains what happened as
> well as the original idea (which _is_ worth using):
>
> http://www.joelonsoftware.com/articles/Wrong.html

Interesting read. A question: I'd assume that with modern languages it'd be possible to achieve much or all (or more) of the safety created by "Apps Hungarian" by using an appropriately crafted type system. E.g. to take one example from that article, create a SafeString type which is guaranteed to contain properly encoded text.

On Sunday, June 02, 2013 02:08:15 Joseph Rushton Wakeling wrote:
> On Saturday, 1 June 2013 at 22:16:49 UTC, Jonathan M Davis wrote:
> > The sad thing is that we got hungarian notation due to a
> > misunderstanding. The
> > original idea was actually quite good. This article explains
> > what happened as
> > well as the original idea (which _is_ worth using):
> > 
> > http://www.joelonsoftware.com/articles/Wrong.html
> 
> Interesting read. A question: I'd assume that with modern languages it'd be possible to achieve much or all (or more) of the safety created by "Apps Hungarian" by using an appropriately crafted type system. E.g. to take one example from that article, create a SafeString type which is guaranteed to contain properly encoded text.

Sure, you could create wrapper types if you wanted to. That's a more heavyweight solution, since you have to create new types, but it's also safer, because the type system helps you out rather than just the names helping the programmer understand the code.

- Jonathan M Davis