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.
66  3644 
Never been to Hungary but I personally prefer to prefix all objects with a
3-character code which signifies what kind of object it is. I started doing
this in VB5 way back when but now in VB2005 it turns out to be even more
useful since I can't ask the class name of an object anymore... When I loop
through a form's control collection the first 3 characters tell me exactly
what it is.
Martin
"CMM" <cm*@nospam.com> wrote in message
news:%2****************@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.
"Martin" <x@y.com> wrote in message
news:Oj**************@TK2MSFTNGP12.phx.gbl... Never been to Hungary but I personally prefer to prefix all objects with a
3-character code which signifies what kind of object it is.
That's no problem - three letters gives 17,000-odd possibilities, and
there's
only 4,000-odd classes in the Framework... ;-)
I started doing this in VB5 way back when but now in VB2005 it turns out
to be even more useful since I can't ask the class name of an object
anymore...
What makes you think that?
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" <cm*@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!).
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Herfried,
I have forever hated the use of the underscore in any dataname.
Why not just mMyPrivate instead of m_MyPrivate?
Cor
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:%2***************@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
I've been back and forth on that one myself. I've finally settled on
mMemberVar because it requires one less character to type.
In addition, I typically prefix private shared variables with 'g' versus 'm'
(indicating that its global rather than a member of an instance)
Ralf
--
--
----------------------------------------------------------
* ^~^ ^~^ *
* _ {~ ~} {~ ~} _ *
* /_``>*< >*<''_\ *
* (\--_)++) (++(_--/) *
----------------------------------------------------------
There are no advanced students in Aikido - there are only
competent beginners. There are no advanced techniques -
only the correct application of basic principles.
Cor,
"Cor Ligthert [MVP]" <no************@planet.nl> schrieb: I have forever hated the use of the underscore in any dataname.
Why not just mMyPrivate instead of m_MyPrivate?
My eyes need a visual separator. I do not claim that "_" is ideal for this
purpose, but it's doing its job pretty well...
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:uw*************@TK2MSFTNGP14.phx.gbl...
:
: "CMM" <cm*@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!).
Could you summarize the points being raised in this article for those of us
who don't read German? Thanx,
Ralf
--
--
----------------------------------------------------------
* ^~^ ^~^ *
* _ {~ ~} {~ ~} _ *
* /_``>*< >*<''_\ *
* (\--_)++) (++(_--/) *
----------------------------------------------------------
There are no advanced students in Aikido - there are only
competent beginners. There are no advanced techniques -
only the correct application of basic principles.
"_AnonCoward" <ab****@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,
I did not read your complete article.
* 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.
However this is real something special German speaking people would see. But
it is true. We by instance make in our language from more words one word by
concatenating them (you will often see me that wrong in English doing as
well). I wished that even in our language this notation we are now talking
about was used. Although now is again that we use more and more hyphens.
However who knows where.
Dutch is probably the language with the most imbecile rules and in that ten
deep sub-rules, which are changed almost every 10 years to make it more
crazy.
Cor
"Cor Ligthert [MVP]" <no************@planet.nl> schrieb: * 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.
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.
true. We by instance make in our language from more words one word by
concatenating them (you will often see me that wrong in English doing as
well).
Well, that's common in German too.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
"Cor Ligthert [MVP]" <no************@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
Herfried,
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.
Cor
Thanx. I appreciate the effort.
Ralf
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:uH*************@TK2MSFTNGP14.phx.gbl...
: "_AnonCoward" <ab****@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/>
:
Armin,
Where is that underscore situated on your keyboard. I type with ten fingers,
that underscore is so far on my keyboard, maybe is it that why I don't like
it. However it is for me probably the most that I don't like it because, as
something is underlined than it becomes not visible.
Although don't misunderstand me, your explanation makes sense. Probably I
just take another word in those cases.
:-)
Cor
"Armin Zingler" <az*******@freenet.de> schreef in bericht
news:uX**************@TK2MSFTNGP14.phx.gbl... "Cor Ligthert [MVP]" <no************@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,
"Cor Ligthert [MVP]" <no************@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.
There are few exceptions. "Patent-Motorwagen" could have been written as
"Patentmotorwagen". "100-Kilometer-Reise" is written this way because of
the hyphen between "100" and "Kilometer", otherwise it would have been
written as "Kilometerreise". In the last few years the english language
influenced how composed words are written ("Reservereifenablage" (correct
German) -> "Reserve-Reifen-Ablage" -> "Reserve Reifen Ablage" (incorrect
German)).
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
I hate the underscore too but I still use it a lot of the time. I'm slowing
trying to break away from to and just use the
mVarName convention for module level private variables. For local variables,
I must say, I do like the descriptive name style of:
goneBad.
I no longer feel to then need to prefix the goneBad variable with it's type
prefix however (for instance, goneBad would probably be a boolean). I guess
you call this camelback? I even use this now at the method parameter level.
It's easy and descriptive.
Steve
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:%2***************@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, 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/de...guidelines.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]" <hi***************@gmx.at> wrote in message
news:uH*************@TK2MSFTNGP14.phx.gbl... "_AnonCoward" <ab****@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/>
Yeah... in fact using notation with controls is exactly THE most difficult
thing in .NET. At least with variables I had a fairly nice pattern going
on.... s,i,b, etc for simple types and o for more complex types. The
notation was really just a way for me to show *instantiation* more than
anything else... a way for me to show a piece of text in my source code was
an instantiated variable rather than a static method in an Imported .NET
framework namespace or something like that.
In the new non-hungarian notation, indication of instantiation is done using
the camelCase notation. And controls receieve no notation because they are
after all just properties of the form class and properties don't get noted.
Though they do get prefixed with the Me keyword when being accessed.
I totally agree... and your example is not rare at all. In VB at least using
m_ with the underscore is practically a necessity because of VB's
case-insensitivity.
"Steve Long" <St**********@NoSpam.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
<snip> I'm slowing
trying to break away from to and just use the
mVarName convention for module level private variables.<snip>
Don't bother. VB's case insensitivity makes this exceedingly difficult to
stick to. Your will end up racking your brain to set you variables apart and
avoid collisions. the "m_" notation works beautifully (in VB at least).
"Mitchell S. Honnert" <ne**@REMhonnertOVE.com> wrote in message
news:%2*****************@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.
Dude, like...totally! But seriously, I personally find it valuable to
differentiate between your standard member variables (m_) and your property
member variables (p_). Yes, it's a common convention to use m_ for all
private member variables, but it's not universal nor is it the Microsoft
standard. (Not that they even *have* a naming standard for this, which is
the main point of my previous post.)
As for maintaining my code...you should be so lucky as to maintain my
elegantly designed, easy-to-read code. ;-)
"When I am working on a problem, I never think about beauty. I only think
about how to solve the problem. But when I have finished, if the solution
is not beautiful, I know it is wrong."
- Buckminster Fuller
Mitchell S. Honnert www.UltraID3Lib.com
"CMM" <cm*@nospam.com> wrote in message
news:e7**************@TK2MSFTNGP11.phx.gbl... "Mitchell S. Honnert" <ne**@REMhonnertOVE.com> wrote in message
news:%2*****************@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.
I once worked with a guy who prefixed all his parameters with "p_"
MySub(p_strSomething, p_intBlaBla)
Boy that was annoying!!!
;-)
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" <cm*@nospam.com> wrote in message
news:u%****************@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!!!
;-)
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" <ne**@REMhonnertOVE.com> wrote in message
news:%2******************@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" <cm*@nospam.com> wrote in message
news:u%****************@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!!!
;-)
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" <ne**@REMhonnertOVE.com> wrote in message
news:%2*****************@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/de...guidelines.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]" <hi***************@gmx.at> wrote in message
news:uH*************@TK2MSFTNGP14.phx.gbl... "_AnonCoward" <ab****@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/>
That would be really annoying.
"CMM" <cm*@nospam.com> wrote in message
news:u%****************@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!!!
;-)
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" <St**********@NoSpam.com> wrote in message
news:eM**************@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" <ne**@REMhonnertOVE.com> wrote in message
news:%2*****************@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/de...guidelines.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]" <hi***************@gmx.at> wrote in message
news:uH*************@TK2MSFTNGP14.phx.gbl... > "_AnonCoward" <ab****@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/>
>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.
First off, *I'm* not saying to have camelCase for parameters; Microsoft is.
Look here...
http://msdn.microsoft.com/library/de...guidelines.asp
It's pretty black and white. I happen to agree with MS, but it's their
standard, not mine.
Secondly, in no way am I supporting the use of Hungarian notation. I agree
that its day has passed.
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.
I couldn't agree more. Here's an interesting, *objective* argument against
Hungarian notation. In a framework where your public method can be called
by any number of languages, why would you want to hardcode your parameter
name to a data type name of the source language? Is intCustomer an Integer
in the *calling* language or the language in which it was written? Just
call it customerNum and be done with it. The compiler will tell you if it's
the wrong data type, so why open up the potential for the reader of your
code to think the variable is of one type when it's really another?
- Mitchell S. Honnert
"CMM" <cm*@nospam.com> wrote in message
news:eS*************@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" <ne**@REMhonnertOVE.com> wrote in message
news:%2******************@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" <cm*@nospam.com> wrote in message
news:u%****************@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" <ne**@REMhonnertOVE.com> wrote in message
news:ur**************@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" <St**********@NoSpam.com> wrote in message
news:eM**************@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" <ne**@REMhonnertOVE.com> wrote in message
news:%2*****************@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/de...guidelines.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]" <hi***************@gmx.at> wrote in message
news:uH*************@TK2MSFTNGP14.phx.gbl...
> "_AnonCoward" <ab****@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/>
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" <ne**@REMhonnertOVE.com> wrote in message
news:ur**************@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" <St**********@NoSpam.com> wrote in message
news:eM**************@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" <ne**@REMhonnertOVE.com> wrote in message
news:%2*****************@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/de...guidelines.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]" <hi***************@gmx.at> wrote in message
news:uH*************@TK2MSFTNGP14.phx.gbl...
> "_AnonCoward" <ab****@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,
"Mitchell S. Honnert" <ne**@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/>
"CMM" <cm*@nospam.com> schrieb: 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.
Camel case is messy. Too bad that I do not have enough time to translate my
article to English.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
> 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.) I've chosen to follow this
convention because it seems to most closely follow the overall naming
standards specified elsewhere. But what Microsoft *does* specify is that
camelCase should be used for parameters. As I mentioned in my previous
post, using camelCase for method variables renders this convention useless.
If I'm looking at your code and I see a variable called "customerID", I
think to myself, "OK, according the MS naming standards, only parameters use
camelCase, so customerID must have been passed into this Function. But
that's weird. This Function is called by a Sub which doesn't know what the
ID of the Customer is yet. So how can it be passing it into this Function?
Let me go an look at the definition of customerID...Oh! I see now! The
author of this method must have decided to ignore the Microsoft naming
standard for parameters! It all makes sense now."
- Mitchell S. Honnert
"CMM" <cm*@nospam.com> wrote in message
news:ef**************@TK2MSFTNGP09.phx.gbl... "Mitchell S. Honnert" <ne**@REMhonnertOVE.com> wrote in message
news:ur**************@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" <St**********@NoSpam.com> wrote in message
news:eM**************@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" <ne**@REMhonnertOVE.com> wrote in message
news:%2*****************@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/de...guidelines.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]" <hi***************@gmx.at> wrote in message
news:uH*************@TK2MSFTNGP14.phx.gbl...
> "_AnonCoward" <ab****@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/>
Well, there are some good points here but does any one of you three have a
comment on my "Weird error" post just a few posts down?
It almost sounds like stack corruption but is that possible?
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl... Mitchell,
"Mitchell S. Honnert" <ne**@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/>
>> 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/de...guidelines.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]" <hi***************@gmx.at> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl... Mitchell,
"Mitchell S. Honnert" <ne**@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]" <hi***************@gmx.at> wrote in message
news:en**************@TK2MSFTNGP12.phx.gbl... Camel case is messy. Too bad that I do not have enough time to translate
my article to English.
I thought so to at first (like I said, it took me three years to finally put
100% of myself into it). But, it doesn't get much messier than the old VB
world (as a whole) with its multitude of naming conventions (sSomething,
strSomething, m_Something, mSomething, _Something) with some people (like in
this thread!) using "p_" to denote private class variables and others using
"p_" to denote parameters! If one codes all on their own and don't care that
someday some other developer has to maintain their code, then you can choose
to implement your own (most assuredly not-sanctioned or even standard)
naming convention.
My conversion is still recent. I may change my mind. But so far I see
nothing but liberation and incredibly readable and maintainable code.
"Mitchell S. Honnert" <ne**@REMhonnertOVE.com> wrote in message
news:uL**************@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.
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" <cm*@nospam.com> wrote in message
news:um**************@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" <ne**@REMhonnertOVE.com> wrote in message
news:ur**************@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" <St**********@NoSpam.com> wrote in message
news:eM**************@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" <ne**@REMhonnertOVE.com> wrote in message
news:%2*****************@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/de...guidelines.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]" <hi***************@gmx.at> wrote in message
news:uH*************@TK2MSFTNGP14.phx.gbl...
> "_AnonCoward" <ab****@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/>
Early in the lifecycle of the guidelines (way back in 2002 or so) they did
espouse camelCase for private variable.... but then decided to concentrate
on the PUBLIC object model of classes rather than enter into the fray of all
the arguments going back and forth in the community.
Again, look at all their code samples. Look at the Right-click Code Snippets
in VS2005.... you'll see that you're wrong.
"Mitchell S. Honnert" <ne**@REMhonnertOVE.com> wrote in message
news:ub**************@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/de...guidelines.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]" <hi***************@gmx.at> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl... Mitchell,
"Mitchell S. Honnert" <ne**@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/>
I never said to use camelCase for Method names. I said use camelCase for
private method variables... "locals."
A parameter is a local. Who cares that it was "passed in." Like I said, I
have never in 17 years felt it necessary to care. A local is a local.
What I DO care about is whether the identifier I'm currently dealing with is
a local variable (my variable!), a static member of some imported namespace
(like System, or whatever), a property (setting a property rather than its
underlying *variable* might not be what I want to do!) or a global
subroutine defined in some global module (VB "Module").
It seems to me that nobody even understands what a variable, a static
member, or even a property is. It's all about "instantiation."
"Mitchell S. Honnert" <ne**@REMhonnertOVE.com> wrote in message
news:Or**************@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" <cm*@nospam.com> wrote in message
news:um**************@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" <ne**@REMhonnertOVE.com> wrote in message
news:ur**************@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" <St**********@NoSpam.com> wrote in message
news:eM**************@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" <ne**@REMhonnertOVE.com> wrote in message
news:%2*****************@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/de...guidelines.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]" <hi***************@gmx.at> wrote in message
> news:uH*************@TK2MSFTNGP14.phx.gbl...
> > "_AnonCoward" <ab****@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/>
>
>
> 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.
"Super-non-standard"? Please, let's not get melodramatic here. I use the
p_ prefix in my own code, but I'll be the first to admit that you probably
wouldn't find it "in the wilds", so to speak.
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
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.
Don't make the mistake of thinking that just because you interpret a naming
standard in a particular way, that I'm dismissing the later developers who
might have to maintain my code. It's for the very reason that I've *been*
that developer who has had to maintain other people's code that I'm so
passionate about naming standards.
- Mitchell S. Honnert
"CMM" <cm*@nospam.com> wrote in message
news:%2***************@tk2msftngp13.phx.gbl... "Mitchell S. Honnert" <ne**@REMhonnertOVE.com> wrote in message
news:uL**************@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.
"Mitchell S. Honnert" <ne**@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/de...guidelines.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/>
"Phill W." <p-***********@o-p-e-n.a-c.u-k> wrote in message
news:dr**********@yarrow.open.ac.uk... "Martin" <x@y.com> wrote in message
news:Oj**************@TK2MSFTNGP12.phx.gbl... Never been to Hungary but I personally prefer to prefix all objects with
a 3-character code which signifies what kind of object it is.
That's no problem - three letters gives 17,000-odd possibilities, and
there's
only 4,000-odd classes in the Framework... ;-)
And it's easier to read at a glance in the source code. btnOK is a lot more
clear than bOK ;-)
I started doing this in VB5 way back when but now in VB2005 it turns out
to be even more useful since I can't ask the class name of an object
anymore...
What makes you think that?
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.
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
??
That looks pretty cool! Wish I had know that...
Regards,
Phill W.
"CMM" <cm*@nospam.com> schrieb: You're still sticking to good ol' typeName notation right (sThis, iThat or
strThis, txtThat)?
I was too until about two weeks ago. I suggest you give dropping it a try.
I stick to "all pascal case" + 'm_' prefix for private fields. I only use
Systems Hungarian when working with 'Option Strict Off', in some late-bound
Office automation scenarios ('appExcel', 'docReadMe', etc.).
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
"Martin" <x@y.com> wrote in message
news:uB**************@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?
I'll have a look if I can find that book. The thing is... the country where
I currently live isn't very rich on these kind of books. I'm programming a
class library in VB2005 to replace our control and function library of VB6
with a Sybex book on my lap. The thing is.... this book is written for
VB.Net 2003. And it seems that especially in the area VB2005 has changed
significantly. The whole 'inherits' thing is in a seperate file now
(mycontrol.designer.vb) which doesn't seem to be intended for editing.
Therefore the examples in the book don't really work.
If I want to make a sub class of for instance the Textbox control, the book
tells me to create a user control and replace the 'inherits
system.wondows.forms.usercontrol' statement with 'inherits textbox' But the
inherits statement is in that hidden designer file. When I change it there,
it leads to a whole bunch of errors and can't open in the designer no
longer...
If you could give me a few pointers here, I'd really appreciate it.
Martin
"CMM" <cm*@nospam.com> wrote in message
news:Og**************@TK2MSFTNGP14.phx.gbl... "Martin" <x@y.com> wrote in message
news:uB**************@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?
> 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).
Now who's assuming? Because "everyone everywhere" that *you* see follows
your version of the naming standard, then anyone else is "bad" and
"super-nonstandard"? Look, naming standards in general are subjective. As
you pointed out, even Hungarian notation has different versions. (Is it
iCustomerNum or intCustomerNum?) My main assertion is that without an
objective statement from Microsoft, the naming conventions are left to the
subjective interpretation of the developer. You seem pretty adamant that
using PascalCase for local variables is a very bad thing. My take on it is
that there are pros and cons to any given standard and that short of a clear
statement from Microsoft, people are going to use what they think makes
sense. 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.
- Mitchell S. Honnert
"CMM" <cm*@nospam.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl... "Mitchell S. Honnert" <ne**@REMhonnertOVE.com> wrote in message
news:Ot**************@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.
"Mitchell S. Honnert" <ne**@REMhonnertOVE.com> wrote in message
news:uM****************@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. This thread has been closed and replies have been disabled. Please start a new discussion. |
