www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Suggestion for a mixed camelCase & PascalCase notation

reply "D-Sturbed" <someone somewhere.fr> writes:
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.
Jun 01 2013
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.
Jun 01 2013
prev sibling next sibling parent "D-Sturbed" <someone somewhere.fr> writes:
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 ;)
Jun 01 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
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.
Jun 01 2013
prev sibling next sibling parent "D-Sturbed" <someone somewhere.fr> writes:
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...
Jun 01 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jun 01 2013
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
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
Jun 01 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jun 01 2013
prev sibling next sibling parent "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
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.
Jun 01 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jun 01 2013
prev sibling next sibling parent "w0rp" <devw0rp gmail.com> writes:
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.
Jun 02 2013
prev sibling next sibling parent "D-Sturbed" <burg.basile yahoo.com> writes:
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..."
Jun 04 2013
prev sibling next sibling parent "D-Sturbed" <burg.basile yahoo.com> writes:
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.
Jun 04 2013
prev sibling parent "Gary Willoughby" <dev kalekold.net> writes:
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.
Jun 04 2013