"CMM" <cmm@nospam.com> wrote in message
news:%23EsQR8kJGHA.3064@TK2MSFTNGP10.phx.gbl...
> So after three years of working in .NET and stubbornly holding on to my
> old hungarian notation practices--- I resolved to try to rid myself of the
> habit. Man, I gotta say that it is liberating!!! I love it.
>
> At first I struggled with how to name controls. I tried to keep some sort
> of notation with them... but I threw that away too!!! I now name them as
> if they were simply properties of the form (FirstNameLabel, etc.)... which
> they ARE!... and when I reference them I use the Me keyword (as all
> properties of a class should be referenced). Pure joy!
>
> Alas, I still use "m_" to indicate private class scoped variables. It
> helps to set them apart from properties and with avoiding collisions with
> property names... because, well, VB is not case sensitive like C#!!! This
> causes problems as in the following example:
>
>    Private firstName As String
>    Public Property FirstName() As String
>        Get
>            Return firstName
>        End Get
>        Set(ByVal value As String)
>            firstName = value
>        End Set
>    End Property
>
> I recommend that any hold outs (you know you're out there!) give it a try.
> It's like a big weight is lifted from your shoulders.
>

>
>> When I loop through a form's control collection the first 3 characters
>> tell me exactly what it is.
>
> And what's wrong with
>
> For Each ctl As Control in Me.Controls
>
>    If TypeOf ctl Is TextBox Then
>        . . .
>    ElseIf TypeOf ctl Is ListBox Then
>        . . .
>    End If
>
> Next
>
> ??

>
> Regards,
>    Phill  W.
>
>

"CMM" <cmm@nospam.com> wrote in message
news:OgwwF4rJGHA.2040@TK2MSFTNGP14.phx.gbl...
> "Martin" <x@y.com> wrote in message
> news:uBJt1urJGHA.1124@TK2MSFTNGP10.phx.gbl...
> <snip>
>> Well, I'm just beginning to leave my trusted VB6 for VB2005 and had to
>> buy a book because the VB2005 help system is utterly and totally useless.
>> Of course no time to read the entire book from cover to cover, but I did
>> read it somewhere in there.
>>
>
> I found Dan Appleman's (yeah the VB6 Guru API GOD) "Moving to VB.NET" book
> to be extremely helpful as a fantastically concise primer illustrating the
> "main differences" between VB.NET and VB.Classic.
>
>> <code snipped>
>>That looks pretty cool! Wish I had know that...
>
> Didn't that work in VB4/5/6 also?
>

"Armin Zingler" <az.nospam@freenet.de> schreef in bericht
news:uX9mAunJGHA.2900@TK2MSFTNGP14.phx.gbl...
> "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> schrieb
>> Herfried,
>>
>> I have forever hated the use of the underscore in any dataname.
>>
>> Why not just mMyPrivate instead of m_MyPrivate?
>
>
> private mMember as integer
> private mEmber as integer    'oops, is property, too.
>
> public property Ember
> '...
> end property
>
> public property Member
> '...
> end property
>
> Doesn't work. ;-) Well, rare case but possible. Avoidable with "_" (if "_"
> is not used with property names). I use the underscore for visual clarity
> and for better intellisense, but I also see the drawback of "hidden"
> underscores for the last declaration if the "procedure separator line" is
> active in the editor - but that's only one declaration and not that
> important.
>
> I use the prefix "f_".  f = Field. Only for those that also have a
> property.
> For other fields I don't use a prefix, just like I do not use "fun_" for
> functions or "prop_" for properties. Fields and other members are on the
> same level, thus I don't distinguish in the usage of a prefix. But I also
> make exceptions, like "txt" for textboxes (or others for controls) which
> are also fields.
>
> My 2 Eurocents.
>
>
> Armin
>

"Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message
news:%23RIVW6mJGHA.524@TK2MSFTNGP09.phx.gbl...
> Herfried,
>
> I have forever hated the use of the underscore in any dataname.
>
> Why not just mMyPrivate instead of m_MyPrivate?
>
> Cor
>
>

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
news:uwk1C0mJGHA.648@TK2MSFTNGP14.phx.gbl...
:
: "CMM" <cmm@nospam.com> schrieb:
: >
: > So after three years of working in .NET and stubbornly holding on to my
: > old hungarian notation practices--- I resolved to try to rid myself of
: > the habit. Man, I gotta say that it is liberating!!! I love it.
:
: Well, I do not use type prefixes ("Systems Hungarian") because I use
: 'Option Strict On' most of the time.  However, I use type prefixes when
: dealing with late binding (variables typed as 'Object').  Additionally
: I use the 'm_' prefix to mark private fields, and I tend to use Apps
: Hungarian because it still makes sense in strictly-typed languages.
:
: On a side note:  I still refuse to use camel case for the reasons listed
: in <URL:http://dotnet.mvps.org/dotnet/articles/camelcase/> (German
: article!).

"_AnonCoward" <abc***@uvwxyz.com> schrieb:
> : > So after three years of working in .NET and stubbornly holding on to
> my
> : > old hungarian notation practices--- I resolved to try to rid myself of
> : > the habit. Man, I gotta say that it is liberating!!! I love it.
> :
> : Well, I do not use type prefixes ("Systems Hungarian") because I use
> : 'Option Strict On' most of the time.  However, I use type prefixes when
> : dealing with late binding (variables typed as 'Object').  Additionally
> : I use the 'm_' prefix to mark private fields, and I tend to use Apps
> : Hungarian because it still makes sense in strictly-typed languages.
> :
> : On a side note:  I still refuse to use camel case for the reasons listed
> : in <URL:http://dotnet.mvps.org/dotnet/articles/camelcase/> (German
> : article!).
>
> Could you summarize the points being raised in this article for those of
> us
> who don't read German? Thanx,

"Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> schrieb:
>>> However this is real something special German speaking people would see.
>>
>> Not really.  Capitalization of initials is common in German, English, and
>> IIRC French, and likely other languages too.
>>
> But not the use of capitals. Just pasted from Bild without any extra
> meaning for the text..
>
> Öffentliches Interesse erregt der Patent-Motorwagen mit der
> 100-Kilometer-Reise von Benz’ Ehefrau Bertha, die 1888 mit dem Wagen von
> Mannheim nach Pforzheim fährt. Eine „Promotion-Tour“, die Benz eine Reihe
> neuer Kunden verschafft. Eine Erfolgsgeschichte beginnt. Nicht nur für
> Karl Benz.

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
news:uHVR$QnJGHA.648@TK2MSFTNGP14.phx.gbl...
: "_AnonCoward" <abc***@uvwxyz.com> schrieb:
: > : > So after three years of working in .NET and stubbornly holding on to
: > my
: > : > old hungarian notation practices--- I resolved to try to rid myself
of
: > : > the habit. Man, I gotta say that it is liberating!!! I love it.
: > :
: > : Well, I do not use type prefixes ("Systems Hungarian") because I use
: > : 'Option Strict On' most of the time.  However, I use type prefixes
when
: > : dealing with late binding (variables typed as 'Object').  Additionally
: > : I use the 'm_' prefix to mark private fields, and I tend to use Apps
: > : Hungarian because it still makes sense in strictly-typed languages.
: > :
: > : On a side note:  I still refuse to use camel case for the reasons
listed
: > : in <URL:http://dotnet.mvps.org/dotnet/articles/camelcase/> (German
: > : article!).
: >
: > Could you summarize the points being raised in this article for those of
: > us
: > who don't read German? Thanx,
:
: The points made in the article are:
:
: *   Distinction of two identifiers (property, backing field) by case only
: can
:    lead to bugs in the implementation which cannot be easily detected.
:
: *   By naming the property using pascal case and the backing field using
:    camel case it's harder to visually detect that both belong to each
: other.
:    This argument is based on a human visual character recognition model.
:
: *   The naming rules described in the .NET Framework Design Guidelines
:    and the internal Guidelines published by Brad Abrams [MSFT] cannot be
:    applied to VB.NET because VB.NET is not case-sensitive.
:
: *   The first character of a word/sentence serves an important role for
:    word recognition.  In classic typography the first letter has often
been
:    written in upper-case and sometimes ornamented to underline its
:    importance.  By starting identifiers' names with a lower-case letter
:    while using upper-case letters inside the identifier this long
tradition
:    in typography is obeyed.
:
: *   Most naming guidelines are made by developers only instead of
:    consulting developers, psychologists, linguists, etc. who have the
:    scientific background to optimize naming guidelines.
:
: --
: M S   Herfried K. Wagner
: M V P  <URL:http://dotnet.mvps.org/>
: V B   <URL:http://classicvb.org/petition/>
:

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
news:uHVR$QnJGHA.648@TK2MSFTNGP14.phx.gbl...
> "_AnonCoward" <abc***@uvwxyz.com> schrieb:
>> : > So after three years of working in .NET and stubbornly holding on to
>> my
>> : > old hungarian notation practices--- I resolved to try to rid myself
>> of
>> : > the habit. Man, I gotta say that it is liberating!!! I love it.
>> :
>> : Well, I do not use type prefixes ("Systems Hungarian") because I use
>> : 'Option Strict On' most of the time.  However, I use type prefixes when
>> : dealing with late binding (variables typed as 'Object').  Additionally
>> : I use the 'm_' prefix to mark private fields, and I tend to use Apps
>> : Hungarian because it still makes sense in strictly-typed languages.
>> :
>> : On a side note:  I still refuse to use camel case for the reasons
>> listed
>> : in <URL:http://dotnet.mvps.org/dotnet/articles/camelcase/> (German
>> : article!).
>>
>> Could you summarize the points being raised in this article for those of
>> us
>> who don't read German? Thanx,
>
> The points made in the article are:
>
> *   Distinction of two identifiers (property, backing field) by case only
> can
>    lead to bugs in the implementation which cannot be easily detected.
>
> *   By naming the property using pascal case and the backing field using
>    camel case it's harder to visually detect that both belong to each
> other.
>    This argument is based on a human visual character recognition model.
>
> *   The naming rules described in the .NET Framework Design Guidelines
>    and the internal Guidelines published by Brad Abrams [MSFT] cannot be
>    applied to VB.NET because VB.NET is not case-sensitive.
>
> *   The first character of a word/sentence serves an important role for
>    word recognition.  In classic typography the first letter has often
> been
>    written in upper-case and sometimes ornamented to underline its
>    importance.  By starting identifiers' names with a lower-case letter
>    while using upper-case letters inside the identifier this long
> tradition
>    in typography is obeyed.
>
> *   Most naming guidelines are made by developers only instead of
>    consulting developers, psychologists, linguists, etc. who have the
>    scientific background to optimize naming guidelines.
>
> --
> M S   Herfried K. Wagner
> M V P  <URL:http://dotnet.mvps.org/>
> V B   <URL:http://classicvb.org/petition/>

"CMM" <cmm@nospam.com> wrote in message
news:e7$OZRpJGHA.1832@TK2MSFTNGP11.phx.gbl...
> "Mitchell S. Honnert" <n***@REMhonnertOVE.com> wrote in message
> news:%23zL%23KfoJGHA.344@TK2MSFTNGP11.phx.gbl...
> <snip>
>> as I can tell, they don't say how to name private member variables like
>> the private "backing field" for a property.  I use a "p_" prefix to
>> differentiate these private member variables as those used by properties,
>> but this is just my convention that I use for lack of being able to find
>> anything definitive from MS.
>
> Dude, the longest standing tradition since like the beginning of time is
> to use "m_" for this... why make "your own" rule. I WOULD HATE to have to
> maintain your code.
>

"CMM" <cmm@nospam.com> wrote in message
news:u%23X8icpJGHA.3144@TK2MSFTNGP11.phx.gbl...
>I once worked with a guy who prefixed all his parameters with "p_"
> MySub(p_strSomething, p_intBlaBla)
> Boy that was annoying!!!
> ;-)
>
>
>

"Mitchell S. Honnert" <n***@REMhonnertOVE.com> wrote in message
news:%23Q7J%23jpJGHA.1760@TK2MSFTNGP10.phx.gbl...
> Like Herfried, I'm not a big fan of camelCase, but from what I can tell,
> Microsoft have limited its use to parameters.  I've adopted this standard
> in my code and I personally find if very valuable to know at-a-glance if a
> particular variable was passed into a method.  Especially considering that
> there are likely to be very similarly-named variables in the same method.
> So, your co-worker was ignoring two (count'em, two!) of MS's naming
> stanrards in one fell swoop.  Annoying...agreed.
>
> - Mitchell S. Honnert
>
>
> "CMM" <cmm@nospam.com> wrote in message
> news:u%23X8icpJGHA.3144@TK2MSFTNGP11.phx.gbl...
>>I once worked with a guy who prefixed all his parameters with "p_"
>> MySub(p_strSomething, p_intBlaBla)
>> Boy that was annoying!!!
>> ;-)
>>
>>
>>
>
>

"CMM" <cmm@nospam.com> wrote in message
news:eSXzuqpJGHA.524@TK2MSFTNGP09.phx.gbl...
> IMHO, if you think about it, it doesn't much matter whether a variable is
> passed into or dimensioned in the method. Having camelCase for parameters
> and hungarian notation for your own method-declared variables (is that
> what you were stating?) is way confusing and messy in my opinion.
>
> And I'm not saying hungarian notation isn't useful... but once you get
> passed the mental hangups on it, you might see that its benefits are not
> enough to justify their hassle. At least I did... and I was stoic believer
> in them- and still am in some ways. But in .NET they make your code MORE
> inconsistent... and for me CONSISTENCY is waaaay more important than
> anything else.
>
>
> "Mitchell S. Honnert" <n***@REMhonnertOVE.com> wrote in message
> news:%23Q7J%23jpJGHA.1760@TK2MSFTNGP10.phx.gbl...
>> Like Herfried, I'm not a big fan of camelCase, but from what I can tell,
>> Microsoft have limited its use to parameters.  I've adopted this standard
>> in my code and I personally find if very valuable to know at-a-glance if
>> a particular variable was passed into a method.  Especially considering
>> that there are likely to be very similarly-named variables in the same
>> method. So, your co-worker was ignoring two (count'em, two!) of MS's
>> naming stanrards in one fell swoop.  Annoying...agreed.
>>
>> - Mitchell S. Honnert
>>
>>
>> "CMM" <cmm@nospam.com> wrote in message
>> news:u%23X8icpJGHA.3144@TK2MSFTNGP11.phx.gbl...
>>>I once worked with a guy who prefixed all his parameters with "p_"
>>> MySub(p_strSomething, p_intBlaBla)
>>> Boy that was annoying!!!
>>> ;-)
>>>
>>>
>>>
>>
>>
>
>

"CMM" <cmm@nospam.com> wrote in message
news:u%23X8icpJGHA.3144@TK2MSFTNGP11.phx.gbl...
> I once worked with a guy who prefixed all his parameters with "p_"
> MySub(p_strSomething, p_intBlaBla)
> Boy that was annoying!!!
> ;-)
>
>
>

"Mitchell S. Honnert" <n***@REMhonnertOVE.com> wrote in message
news:%23zL%23KfoJGHA.344@TK2MSFTNGP11.phx.gbl...
> Herfried, I don't read German, so I haven't read your article, but I do
have
> a question about your first summarized point...
> > *   Distinction of two identifiers (property, backing field) by case
only
> > can
> >    lead to bugs in the implementation which cannot be easily detected.
> As far as I can tell, the only place in the .NET naming standard where it
> says to use camelCase is for parameters.  (I think there may be have been
> one other variable type where they recommended camelCase, but if I
remember
> correctly, it was very rarely used.)  So, the point you are making doesn't
> appear to apply MS's naming standards.
>
> In other words, MS never says to use camelCase for "backing field"
> variables, as in the example...
> >Private firstName As String
>
> At least, it never says it on any official MS web page that I have found.
> Here's where I have been looking.
>

>
> Is there some other reference that you are using?  Do you have a
particular
> link that says to use camelCase for variables other than parameters?
(I've
> seen camelCase used inconsistently in MS's own VB.NET sample code, but
this
> probably has more to do with the authors of the sample code being C#
people
> than evidence of any particular naming standard.)
>
> The problem I have is that MS states explicitly what naming convention to
> use for Classes, Namespaces, Parameters, Methods, and Properties, but as
far
> as I can tell, they don't say how to name private member variables like
the
> private "backing field" for a property.  I use a "p_" prefix to
> differentiate these private member variables as those used by properties,
> but this is just my convention that I use for lack of being able to find
> anything definitive from MS.
>
> Regards,
>
>  - Mitchell S. Honnert
>
>
> "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
> news:uHVR$QnJGHA.648@TK2MSFTNGP14.phx.gbl...
> > "_AnonCoward" <abc***@uvwxyz.com> schrieb:
> >> : > So after three years of working in .NET and stubbornly holding on
to
> >> my
> >> : > old hungarian notation practices--- I resolved to try to rid myself
> >> of
> >> : > the habit. Man, I gotta say that it is liberating!!! I love it.
> >> :
> >> : Well, I do not use type prefixes ("Systems Hungarian") because I use
> >> : 'Option Strict On' most of the time.  However, I use type prefixes
when
> >> : dealing with late binding (variables typed as 'Object').
Additionally
> >> : I use the 'm_' prefix to mark private fields, and I tend to use Apps
> >> : Hungarian because it still makes sense in strictly-typed languages.
> >> :
> >> : On a side note:  I still refuse to use camel case for the reasons
> >> listed
> >> : in <URL:http://dotnet.mvps.org/dotnet/articles/camelcase/> (German
> >> : article!).
> >>
> >> Could you summarize the points being raised in this article for those
of
> >> us
> >> who don't read German? Thanx,
> >
> > The points made in the article are:
> >
> > *   Distinction of two identifiers (property, backing field) by case
only
> > can
> >    lead to bugs in the implementation which cannot be easily detected.
> >
> > *   By naming the property using pascal case and the backing field using
> >    camel case it's harder to visually detect that both belong to each
> > other.
> >    This argument is based on a human visual character recognition model.
> >
> > *   The naming rules described in the .NET Framework Design Guidelines
> >    and the internal Guidelines published by Brad Abrams [MSFT] cannot be
> >    applied to VB.NET because VB.NET is not case-sensitive.
> >
> > *   The first character of a word/sentence serves an important role for
> >    word recognition.  In classic typography the first letter has often
> > been
> >    written in upper-case and sometimes ornamented to underline its
> >    importance.  By starting identifiers' names with a lower-case letter
> >    while using upper-case letters inside the identifier this long
> > tradition
> >    in typography is obeyed.
> >
> > *   Most naming guidelines are made by developers only instead of
> >    consulting developers, psychologists, linguists, etc. who have the
> >    scientific background to optimize naming guidelines.
> >
> > --
> > M S   Herfried K. Wagner
> > M V P  <URL:http://dotnet.mvps.org/>
> > V B   <URL:http://classicvb.org/petition/>
>
>

"Steve Long" <Steve_Noneya@NoSpam.com> wrote in message
news:eMIaPvpJGHA.2864@TK2MSFTNGP10.phx.gbl...
> Oh, the only reason I do it for local variables is for easier
> identification. It's easier to seperate out:
> goneBad
> than it is to seperate out:
> gonebad
>
>
> "Mitchell S. Honnert" <n***@REMhonnertOVE.com> wrote in message
> news:%23zL%23KfoJGHA.344@TK2MSFTNGP11.phx.gbl...
>> Herfried, I don't read German, so I haven't read your article, but I do
> have
>> a question about your first summarized point...
>> > *   Distinction of two identifiers (property, backing field) by case
> only
>> > can
>> >    lead to bugs in the implementation which cannot be easily detected.
>> As far as I can tell, the only place in the .NET naming standard where it
>> says to use camelCase is for parameters.  (I think there may be have been
>> one other variable type where they recommended camelCase, but if I
> remember
>> correctly, it was very rarely used.)  So, the point you are making
>> doesn't
>> appear to apply MS's naming standards.
>>
>> In other words, MS never says to use camelCase for "backing field"
>> variables, as in the example...
>> >Private firstName As String
>>
>> At least, it never says it on any official MS web page that I have found.
>> Here's where I have been looking.
>>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnamingguidelines.asp
>>
>> Is there some other reference that you are using?  Do you have a
> particular
>> link that says to use camelCase for variables other than parameters?
> (I've
>> seen camelCase used inconsistently in MS's own VB.NET sample code, but
> this
>> probably has more to do with the authors of the sample code being C#
> people
>> than evidence of any particular naming standard.)
>>
>> The problem I have is that MS states explicitly what naming convention to
>> use for Classes, Namespaces, Parameters, Methods, and Properties, but as
> far
>> as I can tell, they don't say how to name private member variables like
> the
>> private "backing field" for a property.  I use a "p_" prefix to
>> differentiate these private member variables as those used by properties,
>> but this is just my convention that I use for lack of being able to find
>> anything definitive from MS.
>>
>> Regards,
>>
>>  - Mitchell S. Honnert
>>
>>
>> "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
>> news:uHVR$QnJGHA.648@TK2MSFTNGP14.phx.gbl...
>> > "_AnonCoward" <abc***@uvwxyz.com> schrieb:
>> >> : > So after three years of working in .NET and stubbornly holding on
> to
>> >> my
>> >> : > old hungarian notation practices--- I resolved to try to rid
>> >> myself
>> >> of
>> >> : > the habit. Man, I gotta say that it is liberating!!! I love it.
>> >> :
>> >> : Well, I do not use type prefixes ("Systems Hungarian") because I use
>> >> : 'Option Strict On' most of the time.  However, I use type prefixes
> when
>> >> : dealing with late binding (variables typed as 'Object').
> Additionally
>> >> : I use the 'm_' prefix to mark private fields, and I tend to use Apps
>> >> : Hungarian because it still makes sense in strictly-typed languages.
>> >> :
>> >> : On a side note:  I still refuse to use camel case for the reasons
>> >> listed
>> >> : in <URL:http://dotnet.mvps.org/dotnet/articles/camelcase/> (German
>> >> : article!).
>> >>
>> >> Could you summarize the points being raised in this article for those
> of
>> >> us
>> >> who don't read German? Thanx,
>> >
>> > The points made in the article are:
>> >
>> > *   Distinction of two identifiers (property, backing field) by case
> only
>> > can
>> >    lead to bugs in the implementation which cannot be easily detected.
>> >
>> > *   By naming the property using pascal case and the backing field
>> > using
>> >    camel case it's harder to visually detect that both belong to each
>> > other.
>> >    This argument is based on a human visual character recognition
>> > model.
>> >
>> > *   The naming rules described in the .NET Framework Design Guidelines
>> >    and the internal Guidelines published by Brad Abrams [MSFT] cannot
>> > be
>> >    applied to VB.NET because VB.NET is not case-sensitive.
>> >
>> > *   The first character of a word/sentence serves an important role for
>> >    word recognition.  In classic typography the first letter has often
>> > been
>> >    written in upper-case and sometimes ornamented to underline its
>> >    importance.  By starting identifiers' names with a lower-case letter
>> >    while using upper-case letters inside the identifier this long
>> > tradition
>> >    in typography is obeyed.
>> >
>> > *   Most naming guidelines are made by developers only instead of
>> >    consulting developers, psychologists, linguists, etc. who have the
>> >    scientific background to optimize naming guidelines.
>> >
>> > --
>> > M S   Herfried K. Wagner
>> > M V P  <URL:http://dotnet.mvps.org/>
>> > V B   <URL:http://classicvb.org/petition/>
>>
>>
>
>

>
> - Mitchell S. Honnert
>
> "Steve Long" <Steve_Noneya@NoSpam.com> wrote in message
> news:eMIaPvpJGHA.2864@TK2MSFTNGP10.phx.gbl...
>> Oh, the only reason I do it for local variables is for easier
>> identification. It's easier to seperate out:
>> goneBad
>> than it is to seperate out:
>> gonebad
>>
>>
>> "Mitchell S. Honnert" <n***@REMhonnertOVE.com> wrote in message
>> news:%23zL%23KfoJGHA.344@TK2MSFTNGP11.phx.gbl...
>>> Herfried, I don't read German, so I haven't read your article, but I do
>> have
>>> a question about your first summarized point...
>>> > *   Distinction of two identifiers (property, backing field) by case
>> only
>>> > can
>>> >    lead to bugs in the implementation which cannot be easily detected.
>>> As far as I can tell, the only place in the .NET naming standard where
>>> it
>>> says to use camelCase is for parameters.  (I think there may be have
>>> been
>>> one other variable type where they recommended camelCase, but if I
>> remember
>>> correctly, it was very rarely used.)  So, the point you are making
>>> doesn't
>>> appear to apply MS's naming standards.
>>>
>>> In other words, MS never says to use camelCase for "backing field"
>>> variables, as in the example...
>>> >Private firstName As String
>>>
>>> At least, it never says it on any official MS web page that I have
>>> found.
>>> Here's where I have been looking.
>>>
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnamingguidelines.asp
>>>
>>> Is there some other reference that you are using?  Do you have a
>> particular
>>> link that says to use camelCase for variables other than parameters?
>> (I've
>>> seen camelCase used inconsistently in MS's own VB.NET sample code, but
>> this
>>> probably has more to do with the authors of the sample code being C#
>> people
>>> than evidence of any particular naming standard.)
>>>
>>> The problem I have is that MS states explicitly what naming convention
>>> to
>>> use for Classes, Namespaces, Parameters, Methods, and Properties, but as
>> far
>>> as I can tell, they don't say how to name private member variables like
>> the
>>> private "backing field" for a property.  I use a "p_" prefix to
>>> differentiate these private member variables as those used by
>>> properties,
>>> but this is just my convention that I use for lack of being able to find
>>> anything definitive from MS.
>>>
>>> Regards,
>>>
>>>  - Mitchell S. Honnert
>>>
>>>
>>> "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
>>> news:uHVR$QnJGHA.648@TK2MSFTNGP14.phx.gbl...
>>> > "_AnonCoward" <abc***@uvwxyz.com> schrieb:
>>> >> : > So after three years of working in .NET and stubbornly holding on
>> to
>>> >> my
>>> >> : > old hungarian notation practices--- I resolved to try to rid
>>> >> myself
>>> >> of
>>> >> : > the habit. Man, I gotta say that it is liberating!!! I love it.
>>> >> :
>>> >> : Well, I do not use type prefixes ("Systems Hungarian") because I
>>> >> use
>>> >> : 'Option Strict On' most of the time.  However, I use type prefixes
>> when
>>> >> : dealing with late binding (variables typed as 'Object').
>> Additionally
>>> >> : I use the 'm_' prefix to mark private fields, and I tend to use
>>> >> Apps
>>> >> : Hungarian because it still makes sense in strictly-typed languages.
>>> >> :
>>> >> : On a side note:  I still refuse to use camel case for the reasons
>>> >> listed
>>> >> : in <URL:http://dotnet.mvps.org/dotnet/articles/camelcase/> (German
>>> >> : article!).
>>> >>
>>> >> Could you summarize the points being raised in this article for those
>> of
>>> >> us
>>> >> who don't read German? Thanx,
>>> >
>>> > The points made in the article are:
>>> >
>>> > *   Distinction of two identifiers (property, backing field) by case
>> only
>>> > can
>>> >    lead to bugs in the implementation which cannot be easily detected.
>>> >
>>> > *   By naming the property using pascal case and the backing field
>>> > using
>>> >    camel case it's harder to visually detect that both belong to each
>>> > other.
>>> >    This argument is based on a human visual character recognition
>>> > model.
>>> >
>>> > *   The naming rules described in the .NET Framework Design Guidelines
>>> >    and the internal Guidelines published by Brad Abrams [MSFT] cannot
>>> > be
>>> >    applied to VB.NET because VB.NET is not case-sensitive.
>>> >
>>> > *   The first character of a word/sentence serves an important role
>>> > for
>>> >    word recognition.  In classic typography the first letter has often
>>> > been
>>> >    written in upper-case and sometimes ornamented to underline its
>>> >    importance.  By starting identifiers' names with a lower-case
>>> > letter
>>> >    while using upper-case letters inside the identifier this long
>>> > tradition
>>> >    in typography is obeyed.
>>> >
>>> > *   Most naming guidelines are made by developers only instead of
>>> >    consulting developers, psychologists, linguists, etc. who have the
>>> >    scientific background to optimize naming guidelines.
>>> >
>>> > --
>>> > M S   Herfried K. Wagner
>>> > M V P  <URL:http://dotnet.mvps.org/>
>>> > V B   <URL:http://classicvb.org/petition/>
>>>
>>>
>>
>>
>
>

"CMM" <cmm@nospam.com> wrote in message
news:efwMMZqJGHA.1180@TK2MSFTNGP09.phx.gbl...
> "Mitchell S. Honnert" <n***@REMhonnertOVE.com> wrote in message
> news:urGJTHqJGHA.1676@TK2MSFTNGP09.phx.gbl...
>> Why not just GoneBad?  The naming standard for local, private variables
>> may have been stated somewhere is MS's guidelines, but I haven't found it
>> yet. But, in light of the fact that they say to use PascalCase for
>> *everything* in their spec except for parameters, I just use this style
>> for private variables as well.
>
> One would use camelCase on variables to denote *instantiation*. You use
> PascalCase? Wow... if I had my method variables named all PascalCase I
> wouldn't be able to tell what was a method or static property or whatever
> of an imported namespace or property of the class or global function or
> sub in a global VB module. Is MsgBox() a variable or an array... oh wait
> it's a method.... wait... is it? What am I doing?
>
> I personally would be so confused. Do you actually use PascalCase for
> method variables??? Wow that is truly utterly horrible. I would shoot
> myself if I had to maintain your code.
>
>>
>> In fact, if you name your private variable goneBad, you would be
>> rendering as useless the camelCase parameter naming convention.  The
>> whole point of having only parameters be camelCase is that you can
>> identify at-a-glance variables that have been passed into a method.  But
>> if you dimention new variables within the method using camelCase, you've
>> lost this benefit.
>
> Dubious benefit. I have never in the 17 years of coding (since age 13)
> have cared if a variable was dimensioned in the method or passed into it.
> They're both passed in by the compiler really.
>
>>
>> In regards to your "GoneBad", I've adopted what seems to be a common
>> convention of prefixing Boolean variables with "Is" or "Has".  As in,
>> IsClosed or HasGoneBad.  Maybe that's a little too close to Hungarian
>> notation, but it brings a certain level of consistency to the code.
>
> This is common convention for prefixing FUNCTIONS or properties... not
> variables. Again, using PascalCase on instantiated variables is horrid.
>
>>
>> - Mitchell S. Honnert
>>
>> "Steve Long" <Steve_Noneya@NoSpam.com> wrote in message
>> news:eMIaPvpJGHA.2864@TK2MSFTNGP10.phx.gbl...
>>> Oh, the only reason I do it for local variables is for easier
>>> identification. It's easier to seperate out:
>>> goneBad
>>> than it is to seperate out:
>>> gonebad
>>>
>>>
>>> "Mitchell S. Honnert" <n***@REMhonnertOVE.com> wrote in message
>>> news:%23zL%23KfoJGHA.344@TK2MSFTNGP11.phx.gbl...
>>>> Herfried, I don't read German, so I haven't read your article, but I do
>>> have
>>>> a question about your first summarized point...
>>>> > *   Distinction of two identifiers (property, backing field) by case
>>> only
>>>> > can
>>>> >    lead to bugs in the implementation which cannot be easily
>>>> > detected.
>>>> As far as I can tell, the only place in the .NET naming standard where
>>>> it
>>>> says to use camelCase is for parameters.  (I think there may be have
>>>> been
>>>> one other variable type where they recommended camelCase, but if I
>>> remember
>>>> correctly, it was very rarely used.)  So, the point you are making
>>>> doesn't
>>>> appear to apply MS's naming standards.
>>>>
>>>> In other words, MS never says to use camelCase for "backing field"
>>>> variables, as in the example...
>>>> >Private firstName As String
>>>>
>>>> At least, it never says it on any official MS web page that I have
>>>> found.
>>>> Here's where I have been looking.
>>>>
>>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnamingguidelines.asp
>>>>
>>>> Is there some other reference that you are using?  Do you have a
>>> particular
>>>> link that says to use camelCase for variables other than parameters?
>>> (I've
>>>> seen camelCase used inconsistently in MS's own VB.NET sample code, but
>>> this
>>>> probably has more to do with the authors of the sample code being C#
>>> people
>>>> than evidence of any particular naming standard.)
>>>>
>>>> The problem I have is that MS states explicitly what naming convention
>>>> to
>>>> use for Classes, Namespaces, Parameters, Methods, and Properties, but
>>>> as
>>> far
>>>> as I can tell, they don't say how to name private member variables like
>>> the
>>>> private "backing field" for a property.  I use a "p_" prefix to
>>>> differentiate these private member variables as those used by
>>>> properties,
>>>> but this is just my convention that I use for lack of being able to
>>>> find
>>>> anything definitive from MS.
>>>>
>>>> Regards,
>>>>
>>>>  - Mitchell S. Honnert
>>>>
>>>>
>>>> "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
>>>> news:uHVR$QnJGHA.648@TK2MSFTNGP14.phx.gbl...
>>>> > "_AnonCoward" <abc***@uvwxyz.com> schrieb:
>>>> >> : > So after three years of working in .NET and stubbornly holding
>>>> >> on
>>> to
>>>> >> my
>>>> >> : > old hungarian notation practices--- I resolved to try to rid
>>>> >> myself
>>>> >> of
>>>> >> : > the habit. Man, I gotta say that it is liberating!!! I love it.
>>>> >> :
>>>> >> : Well, I do not use type prefixes ("Systems Hungarian") because I
>>>> >> use
>>>> >> : 'Option Strict On' most of the time.  However, I use type prefixes
>>> when
>>>> >> : dealing with late binding (variables typed as 'Object').
>>> Additionally
>>>> >> : I use the 'm_' prefix to mark private fields, and I tend to use
>>>> >> Apps
>>>> >> : Hungarian because it still makes sense in strictly-typed
>>>> >> languages.
>>>> >> :
>>>> >> : On a side note:  I still refuse to use camel case for the reasons
>>>> >> listed
>>>> >> : in <URL:http://dotnet.mvps.org/dotnet/articles/camelcase/> (German
>>>> >> : article!).
>>>> >>
>>>> >> Could you summarize the points being raised in this article for
>>>> >> those
>>> of
>>>> >> us
>>>> >> who don't read German? Thanx,
>>>> >
>>>> > The points made in the article are:
>>>> >
>>>> > *   Distinction of two identifiers (property, backing field) by case
>>> only
>>>> > can
>>>> >    lead to bugs in the implementation which cannot be easily
>>>> > detected.
>>>> >
>>>> > *   By naming the property using pascal case and the backing field
>>>> > using
>>>> >    camel case it's harder to visually detect that both belong to each
>>>> > other.
>>>> >    This argument is based on a human visual character recognition
>>>> > model.
>>>> >
>>>> > *   The naming rules described in the .NET Framework Design
>>>> > Guidelines
>>>> >    and the internal Guidelines published by Brad Abrams [MSFT] cannot
>>>> > be
>>>> >    applied to VB.NET because VB.NET is not case-sensitive.
>>>> >
>>>> > *   The first character of a word/sentence serves an important role
>>>> > for
>>>> >    word recognition.  In classic typography the first letter has
>>>> > often
>>>> > been
>>>> >    written in upper-case and sometimes ornamented to underline its
>>>> >    importance.  By starting identifiers' names with a lower-case
>>>> > letter
>>>> >    while using upper-case letters inside the identifier this long
>>>> > tradition
>>>> >    in typography is obeyed.
>>>> >
>>>> > *   Most naming guidelines are made by developers only instead of
>>>> >    consulting developers, psychologists, linguists, etc. who have the
>>>> >    scientific background to optimize naming guidelines.
>>>> >
>>>> > --
>>>> > M S   Herfried K. Wagner
>>>> > M V P  <URL:http://dotnet.mvps.org/>
>>>> > V B   <URL:http://classicvb.org/petition/>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

"CMM" <cmm@nospam.com> wrote in message
news:%23j4OiHrJGHA.984@tk2msftngp13.phx.gbl...
> "Mitchell S. Honnert" <n***@REMhonnertOVE.com> wrote in message
> news:uLhKTtqJGHA.1312@TK2MSFTNGP09.phx.gbl...
>> Microsoft doesn't take a stand on whether to use PascalCase for method
>> variables.  (At least, not that I've found.)  I've chosen to follow this
>
>
> See my other post. Their guidelines may concentrate on how you should name
> the public OM of your class.... but every single example in MSDN and the
> help files and- even more telling- in the VB Snippet Inserter in VS2005
> uses camelcase for variables. I think Microsoft has pretty much chosen "a
> stand," don't you think?
>
>> Have a look at that link I included before.  There's a pretty basic set
>> of rules for method and property naming that, as far as I can tell, would
>> alleviate any problems you're talking about.  For example, you'd be able
>> to tell that EnrollCustomer was a method and that CustomerNum was a
>> property just by the names themselves.  If you use the convention of
>> using verbs in your method names, you don't need to mess around with
>> casing to make these distinctions.
>
> The problem isn't with Methods or Properties. Yes, proper noun/verb
> grammer is a good thing (but also sometimes runs into problems with
> controls like SendButton... send the button?... send it where?). Even
> better, is the practice of using Me. (this.) when referencing public
> properties and controls (which are just properties)... a very old and
> common convention that I think is still a very good practice.
> Me.SendButton is al lot clearer... tells you right away SendButton is a
> property of your class.
>
> The problem I was talking about was with naming your LOCALS with the same
> PascalCase convention.
>
> Even if you yourself like it... as developers I think we all have the duty
> to think about people in the future who may have to maintain our code and
> might be confused by your super-non-standard naming conventions.
>
>
>
>
>

"CMM" <cmm@nospam.com> wrote in message
news:%23e374XrJGHA.1088@tk2msftngp13.phx.gbl...
> "Mitchell S. Honnert" <n***@REMhonnertOVE.com> wrote in message
> news:OtnKtRrJGHA.1388@TK2MSFTNGP11.phx.gbl...
>> As for the use of PascalCase, I think it's much more common in the VB
>> world than you think.  Again, given the long history of PascalCase in
>> Visual Basic, it's my impression that the samples you are referring to
>> have more to
> <snip>
>
> I have seen some really bad coding practices in the last 11 years in the
> VB world. I have never seen someone who used PascalCase to name local
> variables.
>
>> do with the fact that the people writing the code are C# people rather
>> than VB people and less to do with any overall master plan on MS's part.
>
> That's an assumption. The fact is that pretty much everybody everywhere
> nowadays uses camelCase for variables (not just VB or C# but also Java...
> obviously). I resisted it.... but a common standard is more important to
> me than my own personal likes and dislikes. I'm not saying its perfect. I
> am saying that it IS CONSISTENT.
>
> At my job I have to maintain several VB and ASP.Classic apps. One VB
> convention is followed in one (sThis, iThat) and another in the other app
> (intThis, lngThat)... and worse (cmdThis, btnThat) and even worse
> constructs. A common convention like today's camelCase for vars,
> PascalCase for everything else, etc etc is very liberating and very
> consistent and will make for much more maintainable body of work.
>
>
>
>

"CMM" <cmm@nospam.com> wrote in message
news:%23k8XgesJGHA.2828@TK2MSFTNGP12.phx.gbl...
>
> "Mitchell S. Honnert" <n***@REMhonnertOVE.com> wrote in message
> news:uMHOB%23rJGHA.3224@TK2MSFTNGP09.phx.gbl...
>> My main assertion is that without an objective statement from Microsoft,
>> the naming conventions are left to the subjective interpretation of the
>> developer.
>
> Or the community as a whole.
>
> Standards are great. But, norms are even better. Developers that don't
> follow either are the cause of a lot of the blight in the programming
> world (VB especially-- and unfortunately).
>
>> In my experience, people mostly ignore the specs that *are* explicitly
>> stated by MS anyway, so I'm lucky if the code I see has any semblence of
>> order to it.
>
> Exactly my point.
>
>
>

"CMM" <cmm@nospam.com> wrote in message
news:%23k8XgesJGHA.2828@TK2MSFTNGP12.phx.gbl...
>
> "Mitchell S. Honnert" <n***@REMhonnertOVE.com> wrote in message
> news:uMHOB%23rJGHA.3224@TK2MSFTNGP09.phx.gbl...
>> My main assertion is that without an objective statement from Microsoft,
>> the naming conventions are left to the subjective interpretation of the
>> developer.
>
> Or the community as a whole.
>
> Standards are great. But, norms are even better. Developers that don't
> follow either are the cause of a lot of the blight in the programming
> world (VB especially-- and unfortunately).
>
>> In my experience, people mostly ignore the specs that *are* explicitly
>> stated by MS anyway, so I'm lucky if the code I see has any semblence of
>> order to it.
>
> Exactly my point.
>
>
>

"CMM" <cmm@nospam.com> wrote in message
news:uT0x2PtJGHA.3984@TK2MSFTNGP14.phx.gbl...
> "Mitchell S. Honnert" <n***@REMhonnertOVE.com> wrote in message
> news:%23w$0dnsJGHA.1424@TK2MSFTNGP12.phx.gbl...
>> It actually sounds like we both have the same feeling that a good set of
>> naming standards can be very beneficial.  I guess I just wish that MS
>> would actually jump into the fray and give a definitive ruling rather
>> than leaving it up to assumptions (even reasonable ones) based on sample
>> code.
>
> So forget samples... how about their actual FRAMEWORKS which implement
> their Patterns & Practices and which they distribute as actual source
> code.
> Here's an abridged piece of code (below) from their CompositeUI Block
> released just last month.
>
> Sure looks like camelCase for variables and FullNames for control class
> names is the norm here!!!
> (they even follow through on the concept to module level variables!).
>
> ----
> Private Sub AddCustomerMenuItem()
>
> Dim customerItem As ToolStripMenuItem = New ToolStripMenuItem("Customer")
>
> workItem.UIExtensionSites(...).Add(customerItem)
> workItem.UIExtensionSites.RegisterSite(...)
>
> End Sub
> ----
>
> Besides.. even without MS, the VB developer community should (somehow)
> settle and evolve these standards. Other developer communities have....
> and quite well. Java most notably... but also others. Why can't we? This
> is one of the reasons VB is derided. I shudder every time I have to open
> some large new VB project that somebody else wrote. I never know what
> horrors await me.
>
>

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
news:%23IIxYcyJGHA.2304@TK2MSFTNGP15.phx.gbl...
> "CMM" <cmm@nospam.com> schrieb:
>>> It actually sounds like we both have the same feeling that a good set of
>>> naming standards can be very beneficial.  I guess I just wish that MS
>>> would actually jump into the fray and give a definitive ruling rather
>>> than leaving it up to assumptions (even reasonable ones) based on sample
>>> code.
>>
>> So forget samples... how about their actual FRAMEWORKS which implement
>> their Patterns & Practices and which they distribute as actual source
>> code.
>> Here's an abridged piece of code (below) from their CompositeUI Block
>> released just last month.
>
> Mhm...  What about the core parts of "Microsoft.VisualBasic.dll"?  Pascal
> case everywhere, even for method parameters!  Really great!
>
> BTW:  If people give method parameters ugly (camel case) names only to be
> able to distinguish them from local variables which are pascal case this
> means making an ugly implementation detail visible.  I think it's better
> (although the .NET Framework naming rules say something different) to use
> pascal case for everything which is publically visible (including
> namespaces, classes, methods, properties, fields, and method parameters)
> and maybe use camel case internally.
>
> Just my 2 Euro cents...
>
> --
> M S   Herfried K. Wagner
> M V P  <URL:http://dotnet.mvps.org/>
> V B   <URL:http://classicvb.org/petition/>

"Mitchell S. Honnert" <n***@REMhonnertOVE.com> wrote in message
news:uLhKTtqJGHA.1312@TK2MSFTNGP09.phx.gbl...
>> One would use camelCase on variables to denote *instantiation*.
> Only if one wanted to flout the Microsoft naming standard.  ;-)
>
>>You use PascalCase? Wow... if I had my method variables named all
>>PascalCase I wouldn't be able to tell what was a method or static property
>>or whatever of an imported namespace or property of the class or global
>>function or sub in a global VB module. Is MsgBox() a variable or an
>>array... oh wait it's a method.... wait... is it? What am I doing?
> Have a look at that link I included before.  There's a pretty basic set of
> rules for method and property naming that, as far as I can tell, would
> alleviate any problems you're talking about.  For example, you'd be able
> to tell that EnrollCustomer was a method and that CustomerNum was a
> property just by the names themselves.  If you use the convention of using
> verbs in your method names, you don't need to mess around with casing to
> make these distinctions.
>
>> I personally would be so confused. Do you actually use PascalCase for
>> method variables??? Wow that is truly utterly horrible. I would shoot
>> myself if I had to maintain your code.
> Microsoft doesn't take a stand on whether to use PascalCase for method
> variables.  (At least, not that I've found.)

"Mitchell S. Honnert" <n***@REMhonnertOVE.com> wrote in message
news:urGJTHqJGHA.1676@TK2MSFTNGP09.phx.gbl...
> Why not just GoneBad?  The naming standard for local, private variables
> may have been stated somewhere is MS's guidelines, but I haven't found it
> yet. But, in light of the fact that they say to use PascalCase for
> *everything* in their spec except for parameters, I just use this style
> for private variables as well.
>
> In fact, if you name your private variable goneBad, you would be rendering
> as useless the camelCase parameter naming convention.  The whole point of
> having only parameters be camelCase is that you can identify at-a-glance
> variables that have been passed into a method.  But if you dimention new
> variables within the method using camelCase, you've lost this benefit.
>
> In regards to your "GoneBad", I've adopted what seems to be a common
> convention of prefixing Boolean variables with "Is" or "Has".  As in,
> IsClosed or HasGoneBad.  Maybe that's a little too close to Hungarian
> notation, but it brings a certain level of consistency to the code.
>
> - Mitchell S. Honnert
>
> "Steve Long" <Steve_Noneya@NoSpam.com> wrote in message
> news:eMIaPvpJGHA.2864@TK2MSFTNGP10.phx.gbl...
>> Oh, the only reason I do it for local variables is for easier
>> identification. It's easier to seperate out:
>> goneBad
>> than it is to seperate out:
>> gonebad
>>
>>
>> "Mitchell S. Honnert" <n***@REMhonnertOVE.com> wrote in message
>> news:%23zL%23KfoJGHA.344@TK2MSFTNGP11.phx.gbl...
>>> Herfried, I don't read German, so I haven't read your article, but I do
>> have
>>> a question about your first summarized point...
>>> > *   Distinction of two identifiers (property, backing field) by case
>> only
>>> > can
>>> >    lead to bugs in the implementation which cannot be easily detected.
>>> As far as I can tell, the only place in the .NET naming standard where
>>> it
>>> says to use camelCase is for parameters.  (I think there may be have
>>> been
>>> one other variable type where they recommended camelCase, but if I
>> remember
>>> correctly, it was very rarely used.)  So, the point you are making
>>> doesn't
>>> appear to apply MS's naming standards.
>>>
>>> In other words, MS never says to use camelCase for "backing field"
>>> variables, as in the example...
>>> >Private firstName As String
>>>
>>> At least, it never says it on any official MS web page that I have
>>> found.
>>> Here's where I have been looking.
>>>
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnamingguidelines.asp
>>>
>>> Is there some other reference that you are using?  Do you have a
>> particular
>>> link that says to use camelCase for variables other than parameters?
>> (I've
>>> seen camelCase used inconsistently in MS's own VB.NET sample code, but
>> this
>>> probably has more to do with the authors of the sample code being C#
>> people
>>> than evidence of any particular naming standard.)
>>>
>>> The problem I have is that MS states explicitly what naming convention
>>> to
>>> use for Classes, Namespaces, Parameters, Methods, and Properties, but as
>> far
>>> as I can tell, they don't say how to name private member variables like
>> the
>>> private "backing field" for a property.  I use a "p_" prefix to
>>> differentiate these private member variables as those used by
>>> properties,
>>> but this is just my convention that I use for lack of being able to find
>>> anything definitive from MS.
>>>
>>> Regards,
>>>
>>>  - Mitchell S. Honnert
>>>
>>>
>>> "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
>>> news:uHVR$QnJGHA.648@TK2MSFTNGP14.phx.gbl...
>>> > "_AnonCoward" <abc***@uvwxyz.com> schrieb:
>>> >> : > So after three years of working in .NET and stubbornly holding on
>> to
>>> >> my
>>> >> : > old hungarian notation practices--- I resolved to try to rid
>>> >> myself
>>> >> of
>>> >> : > the habit. Man, I gotta say that it is liberating!!! I love it.
>>> >> :
>>> >> : Well, I do not use type prefixes ("Systems Hungarian") because I
>>> >> use
>>> >> : 'Option Strict On' most of the time.  However, I use type prefixes
>> when
>>> >> : dealing with late binding (variables typed as 'Object').
>> Additionally
>>> >> : I use the 'm_' prefix to mark private fields, and I tend to use
>>> >> Apps
>>> >> : Hungarian because it still makes sense in strictly-typed languages.
>>> >> :
>>> >> : On a side note:  I still refuse to use camel case for the reasons
>>> >> listed
>>> >> : in <URL:http://dotnet.mvps.org/dotnet/articles/camelcase/> (German
>>> >> : article!).
>>> >>
>>> >> Could you summarize the points being raised in this article for those
>> of
>>> >> us
>>> >> who don't read German? Thanx,
>>> >
>>> > The points made in the article are:
>>> >
>>> > *   Distinction of two identifiers (property, backing field) by case
>> only
>>> > can
>>> >    lead to bugs in the implementation which cannot be easily detected.
>>> >
>>> > *   By naming the property using pascal case and the backing field
>>> > using
>>> >    camel case it's harder to visually detect that both belong to each
>>> > other.
>>> >    This argument is based on a human visual character recognition
>>> > model.
>>> >
>>> > *   The naming rules described in the .NET Framework Design Guidelines
>>> >    and the internal Guidelines published by Brad Abrams [MSFT] cannot
>>> > be
>>> >    applied to VB.NET because VB.NET is not case-sensitive.
>>> >
>>> > *   The first character of a word/sentence serves an important role
>>> > for
>>> >    word recognition.  In classic typography the first letter has often
>>> > been
>>> >    written in upper-case and sometimes ornamented to underline its
>>> >    importance.  By starting identifiers' names with a lower-case
>>> > letter
>>> >    while using upper-case letters inside the identifier this long
>>> > tradition
>>> >    in typography is obeyed.
>>> >
>>> > *   Most naming guidelines are made by developers only instead of
>>> >    consulting developers, psychologists, linguists, etc. who have the
>>> >    scientific background to optimize naming guidelines.
>>> >
>>> > --
>>> > M S   Herfried K. Wagner
>>> > M V P  <URL:http://dotnet.mvps.org/>
>>> > V B   <URL:http://classicvb.org/petition/>
>>>
>>>
>>
>>
>
>

"CMM" <cmm@nospam.com> wrote in message
news:umL58jqJGHA.1288@TK2MSFTNGP09.phx.gbl...
> Also, to add to my other reply (concering your use of PascalCase on
> locals... which I find fascinating... like driving by a car crash)...
> Although Microsoft's naming guidelines doc concentrates on the public
> object model of your classes... in every single Example in the Help system
> and in MSDN and even (most notably) in the myriad of "Insert snippet"
> snippets in VS2005 they use camelcase or all lowercase for local method
> variables.
>
> Really simple example: try Insert Snippet -> Filesystem -> Create
> temporary file.
> What do you see?
> Now check out GetTempFileName topic in Help and see what the usage example
> looks like. What do you see?
>
>
> "Mitchell S. Honnert" <n***@REMhonnertOVE.com> wrote in message
> news:urGJTHqJGHA.1676@TK2MSFTNGP09.phx.gbl...
>> Why not just GoneBad?  The naming standard for local, private variables
>> may have been stated somewhere is MS's guidelines, but I haven't found it
>> yet. But, in light of the fact that they say to use PascalCase for
>> *everything* in their spec except for parameters, I just use this style
>> for private variables as well.
>>
>> In fact, if you name your private variable goneBad, you would be
>> rendering as useless the camelCase parameter naming convention.  The
>> whole point of having only parameters be camelCase is that you can
>> identify at-a-glance variables that have been passed into a method.  But
>> if you dimention new variables within the method using camelCase, you've
>> lost this benefit.
>>
>> In regards to your "GoneBad", I've adopted what seems to be a common
>> convention of prefixing Boolean variables with "Is" or "Has".  As in,
>> IsClosed or HasGoneBad.  Maybe that's a little too close to Hungarian
>> notation, but it brings a certain level of consistency to the code.
>>
>> - Mitchell S. Honnert
>>
>> "Steve Long" <Steve_Noneya@NoSpam.com> wrote in message
>> news:eMIaPvpJGHA.2864@TK2MSFTNGP10.phx.gbl...
>>> Oh, the only reason I do it for local variables is for easier
>>> identification. It's easier to seperate out:
>>> goneBad
>>> than it is to seperate out:
>>> gonebad
>>>
>>>
>>> "Mitchell S. Honnert" <n***@REMhonnertOVE.com> wrote in message
>>> news:%23zL%23KfoJGHA.344@TK2MSFTNGP11.phx.gbl...
>>>> Herfried, I don't read German, so I haven't read your article, but I do
>>> have
>>>> a question about your first summarized point...
>>>> > *   Distinction of two identifiers (property, backing field) by case
>>> only
>>>> > can
>>>> >    lead to bugs in the implementation which cannot be easily
>>>> > detected.
>>>> As far as I can tell, the only place in the .NET naming standard where
>>>> it
>>>> says to use camelCase is for parameters.  (I think there may be have
>>>> been
>>>> one other variable type where they recommended camelCase, but if I
>>> remember
>>>> correctly, it was very rarely used.)  So, the point you are making
>>>> doesn't
>>>> appear to apply MS's naming standards.
>>>>
>>>> In other words, MS never says to use camelCase for "backing field"
>>>> variables, as in the example...
>>>> >Private firstName As String
>>>>
>>>> At least, it never says it on any official MS web page that I have
>>>> found.
>>>> Here's where I have been looking.
>>>>
>>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnamingguidelines.asp
>>>>
>>>> Is there some other reference that you are using?  Do you have a
>>> particular
>>>> link that says to use camelCase for variables other than parameters?
>>> (I've
>>>> seen camelCase used inconsistently in MS's own VB.NET sample code, but
>>> this
>>>> probably has more to do with the authors of the sample code being C#
>>> people
>>>> than evidence of any particular naming standard.)
>>>>
>>>> The problem I have is that MS states explicitly what naming convention
>>>> to
>>>> use for Classes, Namespaces, Parameters, Methods, and Properties, but
>>>> as
>>> far
>>>> as I can tell, they don't say how to name private member variables like
>>> the
>>>> private "backing field" for a property.  I use a "p_" prefix to
>>>> differentiate these private member variables as those used by
>>>> properties,
>>>> but this is just my convention that I use for lack of being able to
>>>> find
>>>> anything definitive from MS.
>>>>
>>>> Regards,
>>>>
>>>>  - Mitchell S. Honnert
>>>>
>>>>
>>>> "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
>>>> news:uHVR$QnJGHA.648@TK2MSFTNGP14.phx.gbl...
>>>> > "_AnonCoward" <abc***@uvwxyz.com> schrieb:
>>>> >> : > So after three years of working in .NET and stubbornly holding
>>>> >> on
>>> to
>>>> >> my
>>>> >> : > old hungarian notation practices--- I resolved to try to rid
>>>> >> myself
>>>> >> of
>>>> >> : > the habit. Man, I gotta say that it is liberating!!! I love it.
>>>> >> :
>>>> >> : Well, I do not use type prefixes ("Systems Hungarian") because I
>>>> >> use
>>>> >> : 'Option Strict On' most of the time.  However, I use type prefixes
>>> when
>>>> >> : dealing with late binding (variables typed as 'Object').
>>> Additionally
>>>> >> : I use the 'm_' prefix to mark private fields, and I tend to use
>>>> >> Apps
>>>> >> : Hungarian because it still makes sense in strictly-typed
>>>> >> languages.
>>>> >> :
>>>> >> : On a side note:  I still refuse to use camel case for the reasons
>>>> >> listed
>>>> >> : in <URL:http://dotnet.mvps.org/dotnet/articles/camelcase/> (German
>>>> >> : article!).
>>>> >>
>>>> >> Could you summarize the points being raised in this article for
>>>> >> those
>>> of
>>>> >> us
>>>> >> who don't read German? Thanx,
>>>> >
>>>> > The points made in the article are:
>>>> >
>>>> > *   Distinction of two identifiers (property, backing field) by case
>>> only
>>>> > can
>>>> >    lead to bugs in the implementation which cannot be easily
>>>> > detected.
>>>> >
>>>> > *   By naming the property using pascal case and the backing field
>>>> > using
>>>> >    camel case it's harder to visually detect that both belong to each
>>>> > other.
>>>> >    This argument is based on a human visual character recognition
>>>> > model.
>>>> >
>>>> > *   The naming rules described in the .NET Framework Design
>>>> > Guidelines
>>>> >    and the internal Guidelines published by Brad Abrams [MSFT] cannot
>>>> > be
>>>> >    applied to VB.NET because VB.NET is not case-sensitive.
>>>> >
>>>> > *   The first character of a word/sentence serves an important role
>>>> > for
>>>> >    word recognition.  In classic typography the first letter has
>>>> > often
>>>> > been
>>>> >    written in upper-case and sometimes ornamented to underline its
>>>> >    importance.  By starting identifiers' names with a lower-case
>>>> > letter
>>>> >    while using upper-case letters inside the identifier this long
>>>> > tradition
>>>> >    in typography is obeyed.
>>>> >
>>>> > *   Most naming guidelines are made by developers only instead of
>>>> >    consulting developers, psychologists, linguists, etc. who have the
>>>> >    scientific background to optimize naming guidelines.
>>>> >
>>>> > --
>>>> > M S   Herfried K. Wagner
>>>> > M V P  <URL:http://dotnet.mvps.org/>
>>>> > V B   <URL:http://classicvb.org/petition/>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

"Mitchell S. Honnert" <n***@REMhonnertOVE.com> wrote in message
news:OrJ4fJrJGHA.1388@TK2MSFTNGP11.phx.gbl...
> You make a good point about the code snippets.  However, a precedent has
> been set for MS correcting the format of their autogenerated code.  For
> example, when the 2003 VS.NET IDE autocompleted the property code, it
> would use "Value" as the parameter name in the Set portion.  "But wait,
> Microsoft. In your naming guidelines, you tell me to name all of my
> parameters using camelCase, yet your own autogenerated codes breaks this
> rule and uses PascalCase."  Then in VS.NET 05, this behavior was corrected
> and "value" is used.  Someone must have pointed out that MS wasn't eating
> their own dogfood.
>
> So, yes...it's a good idea to look at sample code and code snippets for
> guidance on naming standards, it's not the end-all-be-all.  Given the lack
> of a definitive statement from MS that we should use camelCase for
> variables defined within a method, I'm left with the subjective option of
> what sounds reasonable to me.  Given the fact that using camelCase would
> render pointless the stated naming standard for parameters in combination
> with the fact that PascalCase is used for everything else, using
> PascalCase for these variables makes sense.
>
> Something just occurred to me about naming method variables...
> Herfried is saying that MS is telling everyone to use camelCase, but that
> everyone shouldn't use camelCase.
> I'm saying that MS doesn't say to use either camelCase or PascalCase, but
> that everyone should use PascalCase.
> And you're saying that Microsoft uses camelCase, so everyone should use
> camelCase.
>
> I think we have all of the bases covered!  :-)
>
> Hmmm...I wonder what FxCop would have to say about all this?
>
> - Mitchell S. Honnert
>
> "CMM" <cmm@nospam.com> wrote in message
> news:umL58jqJGHA.1288@TK2MSFTNGP09.phx.gbl...
>> Also, to add to my other reply (concering your use of PascalCase on
>> locals... which I find fascinating... like driving by a car crash)...
>> Although Microsoft's naming guidelines doc concentrates on the public
>> object model of your classes... in every single Example in the Help
>> system and in MSDN and even (most notably) in the myriad of "Insert
>> snippet" snippets in VS2005 they use camelcase or all lowercase for local
>> method variables.
>>
>> Really simple example: try Insert Snippet -> Filesystem -> Create
>> temporary file.
>> What do you see?
>> Now check out GetTempFileName topic in Help and see what the usage
>> example looks like. What do you see?
>>
>>
>> "Mitchell S. Honnert" <n***@REMhonnertOVE.com> wrote in message
>> news:urGJTHqJGHA.1676@TK2MSFTNGP09.phx.gbl...
>>> Why not just GoneBad?  The naming standard for local, private variables
>>> may have been stated somewhere is MS's guidelines, but I haven't found
>>> it yet. But, in light of the fact that they say to use PascalCase for
>>> *everything* in their spec except for parameters, I just use this style
>>> for private variables as well.
>>>
>>> In fact, if you name your private variable goneBad, you would be
>>> rendering as useless the camelCase parameter naming convention.  The
>>> whole point of having only parameters be camelCase is that you can
>>> identify at-a-glance variables that have been passed into a method.  But
>>> if you dimention new variables within the method using camelCase, you've
>>> lost this benefit.
>>>
>>> In regards to your "GoneBad", I've adopted what seems to be a common
>>> convention of prefixing Boolean variables with "Is" or "Has".  As in,
>>> IsClosed or HasGoneBad.  Maybe that's a little too close to Hungarian
>>> notation, but it brings a certain level of consistency to the code.
>>>
>>> - Mitchell S. Honnert
>>>
>>> "Steve Long" <Steve_Noneya@NoSpam.com> wrote in message
>>> news:eMIaPvpJGHA.2864@TK2MSFTNGP10.phx.gbl...
>>>> Oh, the only reason I do it for local variables is for easier
>>>> identification. It's easier to seperate out:
>>>> goneBad
>>>> than it is to seperate out:
>>>> gonebad
>>>>
>>>>
>>>> "Mitchell S. Honnert" <n***@REMhonnertOVE.com> wrote in message
>>>> news:%23zL%23KfoJGHA.344@TK2MSFTNGP11.phx.gbl...
>>>>> Herfried, I don't read German, so I haven't read your article, but I
>>>>> do
>>>> have
>>>>> a question about your first summarized point...
>>>>> > *   Distinction of two identifiers (property, backing field) by case
>>>> only
>>>>> > can
>>>>> >    lead to bugs in the implementation which cannot be easily
>>>>> > detected.
>>>>> As far as I can tell, the only place in the .NET naming standard where
>>>>> it
>>>>> says to use camelCase is for parameters.  (I think there may be have
>>>>> been
>>>>> one other variable type where they recommended camelCase, but if I
>>>> remember
>>>>> correctly, it was very rarely used.)  So, the point you are making
>>>>> doesn't
>>>>> appear to apply MS's naming standards.
>>>>>
>>>>> In other words, MS never says to use camelCase for "backing field"
>>>>> variables, as in the example...
>>>>> >Private firstName As String
>>>>>
>>>>> At least, it never says it on any official MS web page that I have
>>>>> found.
>>>>> Here's where I have been looking.
>>>>>
>>>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnamingguidelines.asp
>>>>>
>>>>> Is there some other reference that you are using?  Do you have a
>>>> particular
>>>>> link that says to use camelCase for variables other than parameters?
>>>> (I've
>>>>> seen camelCase used inconsistently in MS's own VB.NET sample code, but
>>>> this
>>>>> probably has more to do with the authors of the sample code being C#
>>>> people
>>>>> than evidence of any particular naming standard.)
>>>>>
>>>>> The problem I have is that MS states explicitly what naming convention
>>>>> to
>>>>> use for Classes, Namespaces, Parameters, Methods, and Properties, but
>>>>> as
>>>> far
>>>>> as I can tell, they don't say how to name private member variables
>>>>> like
>>>> the
>>>>> private "backing field" for a property.  I use a "p_" prefix to
>>>>> differentiate these private member variables as those used by
>>>>> properties,
>>>>> but this is just my convention that I use for lack of being able to
>>>>> find
>>>>> anything definitive from MS.
>>>>>
>>>>> Regards,
>>>>>
>>>>>  - Mitchell S. Honnert
>>>>>
>>>>>
>>>>> "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
>>>>> news:uHVR$QnJGHA.648@TK2MSFTNGP14.phx.gbl...
>>>>> > "_AnonCoward" <abc***@uvwxyz.com> schrieb:
>>>>> >> : > So after three years of working in .NET and stubbornly holding
>>>>> >> on
>>>> to
>>>>> >> my
>>>>> >> : > old hungarian notation practices--- I resolved to try to rid
>>>>> >> myself
>>>>> >> of
>>>>> >> : > the habit. Man, I gotta say that it is liberating!!! I love it.
>>>>> >> :
>>>>> >> : Well, I do not use type prefixes ("Systems Hungarian") because I
>>>>> >> use
>>>>> >> : 'Option Strict On' most of the time.  However, I use type
>>>>> >> prefixes
>>>> when
>>>>> >> : dealing with late binding (variables typed as 'Object').
>>>> Additionally
>>>>> >> : I use the 'm_' prefix to mark private fields, and I tend to use
>>>>> >> Apps
>>>>> >> : Hungarian because it still makes sense in strictly-typed
>>>>> >> languages.
>>>>> >> :
>>>>> >> : On a side note:  I still refuse to use camel case for the reasons
>>>>> >> listed
>>>>> >> : in <URL:http://dotnet.mvps.org/dotnet/articles/camelcase/>
>>>>> >> (German
>>>>> >> : article!).
>>>>> >>
>>>>> >> Could you summarize the points being raised in this article for
>>>>> >> those
>>>> of
>>>>> >> us
>>>>> >> who don't read German? Thanx,
>>>>> >
>>>>> > The points made in the article are:
>>>>> >
>>>>> > *   Distinction of two identifiers (property, backing field) by case
>>>> only
>>>>> > can
>>>>> >    lead to bugs in the implementation which cannot be easily
>>>>> > detected.
>>>>> >
>>>>> > *   By naming the property using pascal case and the backing field
>>>>> > using
>>>>> >    camel case it's harder to visually detect that both belong to
>>>>> > each
>>>>> > other.
>>>>> >    This argument is based on a human visual character recognition
>>>>> > model.
>>>>> >
>>>>> > *   The naming rules described in the .NET Framework Design
>>>>> > Guidelines
>>>>> >    and the internal Guidelines published by Brad Abrams [MSFT]
>>>>> > cannot be
>>>>> >    applied to VB.NET because VB.NET is not case-sensitive.
>>>>> >
>>>>> > *   The first character of a word/sentence serves an important role
>>>>> > for
>>>>> >    word recognition.  In classic typography the first letter has
>>>>> > often
>>>>> > been
>>>>> >    written in upper-case and sometimes ornamented to underline its
>>>>> >    importance.  By starting identifiers' names with a lower-case
>>>>> > letter
>>>>> >    while using upper-case letters inside the identifier this long
>>>>> > tradition
>>>>> >    in typography is obeyed.
>>>>> >
>>>>> > *   Most naming guidelines are made by developers only instead of
>>>>> >    consulting developers, psychologists, linguists, etc. who have
>>>>> > the
>>>>> >    scientific background to optimize naming guidelines.
>>>>> >
>>>>> > --
>>>>> > M S   Herfried K. Wagner
>>>>> > M V P  <URL:http://dotnet.mvps.org/>
>>>>> > V B   <URL:http://classicvb.org/petition/>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

"Mitchell S. Honnert" <n***@REMhonnertOVE.com> schrieb:
> Herfried, I don't read German, so I haven't read your article, but I do
> have a question about your first summarized point...
>> *   Distinction of two identifiers (property, backing field) by case only
>> can
>>    lead to bugs in the implementation which cannot be easily detected.
> As far as I can tell, the only place in the .NET naming standard where it
> says to use camelCase is for parameters.  (I think there may be have been
> one other variable type where they recommended camelCase, but if I
> remember correctly, it was very rarely used.)  So, the point you are
> making doesn't appear to apply MS's naming standards.
>
> In other words, MS never says to use camelCase for "backing field"
> variables, as in the example...
>>Private firstName As String
>
> Is there some other reference that you are using?  Do you have a
> particular link that says to use camelCase for variables other than
> parameters?  (I've seen camelCase used inconsistently in MS's own VB.NET
> sample code, but this probably has more to do with the authors of the
> sample code being C# people than evidence of any particular naming
> standard.)

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
news:%23tpYqnqJGHA.3144@TK2MSFTNGP11.phx.gbl...
> Mitchell,
>
> "Mitchell S. Honnert" <n***@REMhonnertOVE.com> schrieb:
> > Herfried, I don't read German, so I haven't read your article, but I do
> > have a question about your first summarized point...
> >> *   Distinction of two identifiers (property, backing field) by case
only
> >> can
> >>    lead to bugs in the implementation which cannot be easily detected.
> > As far as I can tell, the only place in the .NET naming standard where
it
> > says to use camelCase is for parameters.  (I think there may be have
been
> > one other variable type where they recommended camelCase, but if I
> > remember correctly, it was very rarely used.)  So, the point you are
> > making doesn't appear to apply MS's naming standards.
> >
> > In other words, MS never says to use camelCase for "backing field"
> > variables, as in the example...
> >>Private firstName As String
> >
> > Is there some other reference that you are using?  Do you have a
> > particular link that says to use camelCase for variables other than
> > parameters?  (I've seen camelCase used inconsistently in MS's own VB.NET
> > sample code, but this probably has more to do with the authors of the
> > sample code being C# people than evidence of any particular naming
> > standard.)
>
> They do so in the internal naming guidelines and in the "Field Usage
> Guidelines" chapter.  I suggest to take a look at the code snippets on the
> page referenced previously which contains relevant quotes from these
> chapters in English.  The main problem I see is that some teams inside
> Microsoft see C# as the only .NET programming language and design
guidelines
> and samples with C# in mind only.
>
> --
>  M S   Herfried K. Wagner
> M V P  <URL:http://dotnet.mvps.org/>
>  V B   <URL:http://classicvb.org/petition/>
>

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
news:%23tpYqnqJGHA.3144@TK2MSFTNGP11.phx.gbl...
> Mitchell,
>
> "Mitchell S. Honnert" <n***@REMhonnertOVE.com> schrieb:
>> Herfried, I don't read German, so I haven't read your article, but I do
>> have a question about your first summarized point...
>>> *   Distinction of two identifiers (property, backing field) by case
>>> only can
>>>    lead to bugs in the implementation which cannot be easily detected.
>> As far as I can tell, the only place in the .NET naming standard where it
>> says to use camelCase is for parameters.  (I think there may be have been
>> one other variable type where they recommended camelCase, but if I
>> remember correctly, it was very rarely used.)  So, the point you are
>> making doesn't appear to apply MS's naming standards.
>>
>> In other words, MS never says to use camelCase for "backing field"
>> variables, as in the example...
>>>Private firstName As String
>>
>> Is there some other reference that you are using?  Do you have a
>> particular link that says to use camelCase for variables other than
>> parameters?  (I've seen camelCase used inconsistently in MS's own VB.NET
>> sample code, but this probably has more to do with the authors of the
>> sample code being C# people than evidence of any particular naming
>> standard.)
>
> They do so in the internal naming guidelines and in the "Field Usage
> Guidelines" chapter.  I suggest to take a look at the code snippets on the
> page referenced previously which contains relevant quotes from these
> chapters in English.  The main problem I see is that some teams inside
> Microsoft see C# as the only .NET programming language and design
> guidelines and samples with C# in mind only.
>
> --
> M S   Herfried K. Wagner
> M V P  <URL:http://dotnet.mvps.org/>
> V B   <URL:http://classicvb.org/petition/>

"Mitchell S. Honnert" <n***@REMhonnertOVE.com> wrote in message
news:ubMnj8qJGHA.1848@TK2MSFTNGP12.phx.gbl...
>>> Do you have a particular link that says to use camelCase for variables
>>> other than parameters?
>> They do so in the internal naming guidelines and in the "Field Usage
>> Guidelines" chapter.
> Herfried, am I looking in the right place?
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconfieldusageguidelines.asp
>
> If so, then I still hold to my assertion that Microsoft doesn't state
> definitively to use camelCase for variables defined within a method.
> Admittedly, the sample code uses this convention, but as we both have
> pointed out, this is most likely a result of the fact that the VB.NET
> sample code was written by C# developers.  Nowhere do I see a plain
> statement by Microsoft that says, "Use camelCase for local variables in a
> method."
>
> As I've mentioned in other subthreads, using camelCase for variables
> defined within a method would render the use of camelCase for parameters
> as useless. So, surely this can't be what they really mean.  When a
> programmer sees a variable in camelCase format, they know that the only
> place in the Microsoft standards where camelCase is explicitly recommended
> is for parameters, so they know it must be a parameter.
>
> "Use camelCase for parameters and PascalCase for everything else."  That's
> what I get out of reading the MS standards.  camelCase may be messy, but
> given this definition, it's so narrowly defined that it isn't a bid deal.
>
> Mitchell S. Honnert
> www.UltraID3Lib.com
>
>
>
> "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
> news:%23tpYqnqJGHA.3144@TK2MSFTNGP11.phx.gbl...
>> Mitchell,
>>
>> "Mitchell S. Honnert" <n***@REMhonnertOVE.com> schrieb:
>>> Herfried, I don't read German, so I haven't read your article, but I do
>>> have a question about your first summarized point...
>>>> *   Distinction of two identifiers (property, backing field) by case
>>>> only can
>>>>    lead to bugs in the implementation which cannot be easily detected.
>>> As far as I can tell, the only place in the .NET naming standard where
>>> it says to use camelCase is for parameters.  (I think there may be have
>>> been one other variable type where they recommended camelCase, but if I
>>> remember correctly, it was very rarely used.)  So, the point you are
>>> making doesn't appear to apply MS's naming standards.
>>>
>>> In other words, MS never says to use camelCase for "backing field"
>>> variables, as in the example...
>>>>Private firstName As String
>>>
>>> Is there some other reference that you are using?  Do you have a
>>> particular link that says to use camelCase for variables other than
>>> parameters?  (I've seen camelCase used inconsistently in MS's own VB.NET
>>> sample code, but this probably has more to do with the authors of the
>>> sample code being C# people than evidence of any particular naming
>>> standard.)
>>
>> They do so in the internal naming guidelines and in the "Field Usage
>> Guidelines" chapter.  I suggest to take a look at the code snippets on
>> the page referenced previously which contains relevant quotes from these
>> chapters in English.  The main problem I see is that some teams inside
>> Microsoft see C# as the only .NET programming language and design
>> guidelines and samples with C# in mind only.
>>
>> --
>> M S   Herfried K. Wagner
>> M V P  <URL:http://dotnet.mvps.org/>
>> V B   <URL:http://classicvb.org/petition/>
>
>

"Mitchell S. Honnert" <n***@REMhonnertOVE.com> schrieb:
>>> Do you have a particular link that says to use camelCase for variables
>>> other than parameters?
>> They do so in the internal naming guidelines and in the "Field Usage
>> Guidelines" chapter.
> Herfried, am I looking in the right place?
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconfieldusageguidelines.asp
>
> If so, then I still hold to my assertion that Microsoft doesn't state
> definitively to use camelCase for variables defined within a method.
> Admittedly, the sample code uses this convention, but as we both have
> pointed out, this is most likely a result of the fact that the VB.NET
> sample code was written by C# developers.  Nowhere do I see a plain
> statement by Microsoft that says, "Use camelCase for local variables in a
> method."

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
news:eW9LOurJGHA.648@TK2MSFTNGP14.phx.gbl...
> "Mitchell S. Honnert" <n***@REMhonnertOVE.com> schrieb:
>>>> Do you have a particular link that says to use camelCase for variables
>>>> other than parameters?
>>> They do so in the internal naming guidelines and in the "Field Usage
>>> Guidelines" chapter.
>> Herfried, am I looking in the right place?
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconfieldusageguidelines.asp
>>
>> If so, then I still hold to my assertion that Microsoft doesn't state
>> definitively to use camelCase for variables defined within a method.
>> Admittedly, the sample code uses this convention, but as we both have
>> pointed out, this is most likely a result of the fact that the VB.NET
>> sample code was written by C# developers.  Nowhere do I see a plain
>> statement by Microsoft that says, "Use camelCase for local variables in a
>> method."
>
> ACK.  *I* have *never* been talking about local variables and claiming
> that Microsoft recommends camel case for them.
>
> --
> M S   Herfried K. Wagner
> M V P  <URL:http://dotnet.mvps.org/>
> V B   <URL:http://classicvb.org/petition/>

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
news:uxcEwssJGHA.1192@TK2MSFTNGP11.phx.gbl...
> Mitchell,
>
> "Mitchell S. Honnert" <n***@REMhonnertOVE.com> schrieb:
>>> ACK.  *I* have *never* been talking about local variables and claiming
>>> that Microsoft recommends camel case for them.
>>
>> If you don't mind me asking, what naming convention do you use for local
>> variables?
>
> Pascal case, except for variables like 'i', 'j', 's', 't', etc.
>
> --
> M S   Herfried K. Wagner
> M V P  <URL:http://dotnet.mvps.org/>
> V B   <URL:http://classicvb.org/petition/>

"Mitchell S. Honnert" <n***@REMhonnertOVE.com> schreef in bericht
news:u6TicfsJGHA.648@TK2MSFTNGP14.phx.gbl...
>> ACK.  *I* have *never* been talking about local variables and claiming
>> that Microsoft recommends camel case for them.
> Understood.  I think some of the side conversation got onto the topic of
> local variables because of my comments about how I could only find one
> direct recommendation by MS to use camelCase (for parameters).
>
> If you don't mind me asking, what naming convention do you use for local
> variables?
>
> - Mitchell S. Honnert
>
>
> "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
> news:eW9LOurJGHA.648@TK2MSFTNGP14.phx.gbl...
>> "Mitchell S. Honnert" <n***@REMhonnertOVE.com> schrieb:
>>>>> Do you have a particular link that says to use camelCase for variables
>>>>> other than parameters?
>>>> They do so in the internal naming guidelines and in the "Field Usage
>>>> Guidelines" chapter.
>>> Herfried, am I looking in the right place?
>>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconfieldusageguidelines.asp
>>>
>>> If so, then I still hold to my assertion that Microsoft doesn't state
>>> definitively to use camelCase for variables defined within a method.
>>> Admittedly, the sample code uses this convention, but as we both have
>>> pointed out, this is most likely a result of the fact that the VB.NET
>>> sample code was written by C# developers.  Nowhere do I see a plain
>>> statement by Microsoft that says, "Use camelCase for local variables in
>>> a method."
>>
>> ACK.  *I* have *never* been talking about local variables and claiming
>> that Microsoft recommends camel case for them.
>>
>> --
>> M S   Herfried K. Wagner
>> M V P  <URL:http://dotnet.mvps.org/>
>> V B   <URL:http://classicvb.org/petition/>
>
>