digitalmars.D - Suggestion for a mixed camelCase & PascalCase notation
- D-Sturbed (39/39) Jun 01 2013 Hello, I know that everybody will hate that, as most of the
- Nick Sabalausky (8/53) Jun 01 2013 That's basically a variation of hungarian notation, which has been
- D-Sturbed (3/62) Jun 01 2013 And your answer can be seen as an overhead from a douche, I guess
- Namespace (4/4) Jun 01 2013 In my world, every variable or identifier name is chosen so that
- Gary Willoughby (2/7) Jun 04 2013 +1 no need for Hungarian if code is clean.
- D-Sturbed (2/66) Jun 01 2013 Sorry...
- w0rp (9/9) Jun 02 2013 I had a job where we had a convention of using Hungarian notation
- Jonathan M Davis (11/14) Jun 01 2013 This is essentially hungarian notation, which has widely been determined...
- Paulo Pinto (6/42) Jun 01 2013 Lets not keep Hungarian notation alive, now that even Microsoft
- Jonathan M Davis (6/9) Jun 01 2013 The sad thing is that we got hungarian notation due to a misunderstandin...
- Joseph Rushton Wakeling (7/13) Jun 01 2013 Interesting read. A question: I'd assume that with modern
- Jonathan M Davis (6/21) Jun 01 2013 Sure, you could create wrapper types if you wanted to. That's a more
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
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
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:And your answer can be seen as an overhead from a douche, I guess ;)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
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
"Gary Willoughby" <dev kalekold.net> 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
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:Sorry...On Sat, 01 Jun 2013 21:58:27 +0200 "D-Sturbed" <someone somewhere.fr> wrote:And your answer can be seen as an overhead from a douche, I guess ;)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
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: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 Saturday, 1 June 2013 at 20:18:53 UTC, Nick Sabalausky wrote:Sorry...On Sat, 01 Jun 2013 21:58:27 +0200 "D-Sturbed" <someone somewhere.fr> wrote:And your answer can be seen as an overhead from a douche, I guess ;)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 04 2013
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: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:34:42 UTC, D-Sturbed wrote: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 Saturday, 1 June 2013 at 20:18:53 UTC, Nick Sabalausky wrote:Sorry...On Sat, 01 Jun 2013 21:58:27 +0200 "D-Sturbed" <someone somewhere.fr> wrote:And your answer can be seen as an overhead from a douche, I guess ;)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 04 2013
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
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
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
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
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.htmlInteresting 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
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: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 DavisThe 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.htmlInteresting 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