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.
Jan 31 '06
66  3643 
Mitchell,
"Mitchell S. Honnert" <ne**@REMhonnertOVE.com> schrieb: ACK. *I* have *never* been talking about local variables and claiming
that Microsoft recommends camel case for them.
If you don't mind me asking, what naming convention do you use for local
variables?
Pascal case, except for variables like 'i', 'j', 's', 't', etc.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
> ACK. *I* have *never* been talking about local variables and claiming that Microsoft recommends camel case for them.
Understood. I think some of the side conversation got onto the topic of
local variables because of my comments about how I could only find one
direct recommendation by MS to use camelCase (for parameters).
If you don't mind me asking, what naming convention do you use for local
variables?
- Mitchell S. Honnert
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:eW*************@TK2MSFTNGP14.phx.gbl... "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/>
To belabor my point. I'm not saying that modern convention is better than
"your" style... or better than "my" old hungarian notiation style (which I
loved and had utterly perfected!). I am saying that if I look at three
different projects in my day written by three different developers it HELPS
A LOT to see one standard convention used throughout them. Modern coding
standards (perfected in the Java world unfortunately and NOT the VB world to
nobody's surprise) is a good thing.
I hate XML. I think it's a stupid throwback-to-1993 and is bloated and
ill-conceived (I prefer variable-width binary files). But, I use XML... and
I use it alot. It's a standard and everyone understands it. Standards are
key... and maintaining them is key to any company having maintainable code.
"CMM" <cm*@nospam.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
"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.
Wow. I've gone from "super-nonstandard" to be a blight on the development
community. I know that we've reached the As-I've-Already-Stated phase of a
dying thread, but one last time... You may have a very clear and
unambiguous idea of what the "community as a whole" thinks about naming
conventions or whatever, but that doesn't make your interpretation the
truth.
It actually sounds like we both have the same feeling that a good set of
naming standards can be very beneficial. I guess I just wish that MS would
actually jump into the fray and give a definitive ruling rather than leaving
it up to assumptions (even reasonable ones) based on sample code.
That's it for me! Goodnight.
- Mitchell S. Honnert
"CMM" <cm*@nospam.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
"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.
"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.
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.
It's about time the VB community grew up and let go of a lot of its past. We
won't shed the "vb code is messy" and a kiddy, inconsistent, messy language
until we do. The mere fact that some us use "p_" for anything (ack!) and
other "personal preference" constructs is evidence of what gives VB a bad
name (IMO).
"Mitchell S. Honnert" <ne**@REMhonnertOVE.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... It actually sounds like we both have the same feeling that a good set of
naming standards can be very beneficial. I guess I just wish that MS
would actually jump into the fray and give a definitive ruling rather than
leaving it up to assumptions (even reasonable ones) based on sample code.
So forget samples... how about their actual FRAMEWORKS which implement their
Patterns & Practices and which they distribute as actual source code.
Here's an abridged piece of code (below) from their CompositeUI Block
released just last month.
Sure looks like camelCase for variables and FullNames for control class
names is the norm here!!!
(they even follow through on the concept to module level variables!).
----
Private Sub AddCustomerMenuItem()
Dim customerItem As ToolStripMenuItem = New ToolStripMenuItem("Customer")
workItem.UIExtensionSites(...).Add(customerItem)
workItem.UIExtensionSites.RegisterSite(...)
End Sub
----
Besides.. even without MS, the VB developer community should (somehow)
settle and evolve these standards. Other developer communities have.... and
quite well. Java most notably... but also others. Why can't we? This is one
of the reasons VB is derided. I shudder every time I have to open some large
new VB project that somebody else wrote. I never know what horrors await me.
How do you feel about MS's own internal guidelines (which reference VB not
just C#)
"Do use camelCasing for local variables" http://blogs.msdn.com/brada/articles/361363.aspx
I guess they don't make this part of the official Guidelines, which stresses
only the public object model of your classes, for fear of throwing the
community into chaos.... though I think that's exactly what is happening.
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:ux**************@TK2MSFTNGP11.phx.gbl... Mitchell,
"Mitchell S. Honnert" <ne**@REMhonnertOVE.com> schrieb: ACK. *I* have *never* been talking about local variables and claiming
that Microsoft recommends camel case for them.
If you don't mind me asking, what naming convention do you use for local
variables?
Pascal case, except for variables like 'i', 'j', 's', 't', etc.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
And if the VB enterprise frameworks source code isn't enough... how about
their own internal guidelines (which reference VB as well not just C#)?
"Do use camelCasing for local variables" http://blogs.msdn.com/brada/articles/361363.aspx
Like I said in another post concerning this document.... I guess they don't
make this part of the official Guidelines, which stresses
only the public object model of your classes, for fear of throwing the
community into chaos.... though I think the community (VB especially) is in
chaos.
"CMM" <cm*@nospam.com> wrote in message
news:uT**************@TK2MSFTNGP14.phx.gbl... "Mitchell S. Honnert" <ne**@REMhonnertOVE.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... It actually sounds like we both have the same feeling that a good set of
naming standards can be very beneficial. I guess I just wish that MS
would actually jump into the fray and give a definitive ruling rather
than leaving it up to assumptions (even reasonable ones) based on sample
code.
So forget samples... how about their actual FRAMEWORKS which implement
their Patterns & Practices and which they distribute as actual source
code.
Here's an abridged piece of code (below) from their CompositeUI Block
released just last month.
Sure looks like camelCase for variables and FullNames for control class
names is the norm here!!!
(they even follow through on the concept to module level variables!).
----
Private Sub AddCustomerMenuItem()
Dim customerItem As ToolStripMenuItem = New ToolStripMenuItem("Customer")
workItem.UIExtensionSites(...).Add(customerItem)
workItem.UIExtensionSites.RegisterSite(...)
End Sub
----
Besides.. even without MS, the VB developer community should (somehow)
settle and evolve these standards. Other developer communities have....
and quite well. Java most notably... but also others. Why can't we? This
is one of the reasons VB is derided. I shudder every time I have to open
some large new VB project that somebody else wrote. I never know what
horrors await me.
Mitchel,
This discussion is almost 45 years old. (As long as there are symbolic
languages).
As Herfried has stated very well, done mostly by amateurs like you and me
who are just developers.
For the first time since long, it was enlighten me in this, when Herfired
wrote that we had to look for people who do this for profession.
What I have seen is that especially those who this preach this, are as well
those who the most often sin against this.
That the methods are still evaluating is probably because the previous are
wrong. There are a lot of people against camel case. That a person at
Microsoft has once proclaimed that, will not say that he is the messiah.
Just my thought,
Cor
"Mitchell S. Honnert" <ne**@REMhonnertOVE.com> schreef in bericht
news:u6*************@TK2MSFTNGP14.phx.gbl... ACK. *I* have *never* been talking about local variables and claiming
that Microsoft recommends camel case for them.
Understood. I think some of the side conversation got onto the topic of
local variables because of my comments about how I could only find one
direct recommendation by MS to use camelCase (for parameters).
If you don't mind me asking, what naming convention do you use for local
variables?
- Mitchell S. Honnert
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:eW*************@TK2MSFTNGP14.phx.gbl... "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/>
"CMM" <cm*@nospam.com> schrieb: It actually sounds like we both have the same feeling that a good set of
naming standards can be very beneficial. I guess I just wish that MS
would actually jump into the fray and give a definitive ruling rather
than leaving it up to assumptions (even reasonable ones) based on sample
code.
So forget samples... how about their actual FRAMEWORKS which implement
their Patterns & Practices and which they distribute as actual source
code.
Here's an abridged piece of code (below) from their CompositeUI Block
released just last month.
Mhm... What about the core parts of "Microsoft.VisualBasic.dll"? Pascal
case everywhere, even for method parameters! Really great!
BTW: If people give method parameters ugly (camel case) names only to be
able to distinguish them from local variables which are pascal case this
means making an ugly implementation detail visible. I think it's better
(although the .NET Framework naming rules say something different) to use
pascal case for everything which is publically visible (including
namespaces, classes, methods, properties, fields, and method parameters) and
maybe use camel case internally.
Just my 2 Euro cents...
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
"CMM" <cm*@nospam.com> schrieb: And if the VB enterprise frameworks source code isn't enough... how about
their own internal guidelines (which reference VB as well not just C#)?
"Do use camelCasing for local variables"
http://blogs.msdn.com/brada/articles/361363.aspx
Like I said in another post concerning this document.... I guess they
don't make this part of the official Guidelines, which stresses
only the public object model of your classes, for fear of throwing the
community into chaos.... though I think the community (VB especially) is
in chaos.
Those guidelines have not been designed with VB in mind, thus I don't think
they are a good foundation to base new guidelines for VB on. For example,
the following points made in the article technically cannot be applied to
VB:
| * Do not use a prefix for member variables (_, m_, s_, etc.). If
| you want to distinguish between local and member variables you
| should use “this.” in C# and “Me.” in VB.NET.
|
| * Do use camelCasing for member variables
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Cor,
"Cor Ligthert [MVP]" <no************@planet.nl> schrieb: As Herfried has stated very well, done mostly by amateurs like you and me
who are just developers.
Thank you for pointing this important thing out again. In the article I
conclude that most naming guidelines are simply descriptions of practice
instead of a plan which is based on expertise in psychology, design,
linguistics, ... We could find new naming guidlines based on a consensus,
but I believe it's much more important to let real professionals create and
evaluate the guidelines before forcing them on developers. Obviously this
has not been done for the .NET Framework Guidelines and the Internal Coding
Guidelines.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
> Mhm... What about the core parts of "Microsoft.VisualBasic.dll"? Pascal case everywhere, even for method parameters! Really great!
Maybe that's because that namespace duplicates special keywords that have
been in B.A.S.I.C. since as far back as 1977... before BASIC even had the
ability for encapsulated Functions and Subs and was instead a punch-card
style, line-driven programming language.
In fact, everything in that "core part" should be ALL CAPS.... ;-) but
somewhere along the line (VB1? QBASIC? not sure) MS smartly decided this
would be ugly.... but in .NET I guess they kept the Casing for nostalgic
reasons. Who knows.
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl... "CMM" <cm*@nospam.com> schrieb: It actually sounds like we both have the same feeling that a good set of
naming standards can be very beneficial. I guess I just wish that MS
would actually jump into the fray and give a definitive ruling rather
than leaving it up to assumptions (even reasonable ones) based on sample
code.
So forget samples... how about their actual FRAMEWORKS which implement
their Patterns & Practices and which they distribute as actual source
code.
Here's an abridged piece of code (below) from their CompositeUI Block
released just last month.
Mhm... What about the core parts of "Microsoft.VisualBasic.dll"? Pascal
case everywhere, even for method parameters! Really great!
BTW: If people give method parameters ugly (camel case) names only to be
able to distinguish them from local variables which are pascal case this
means making an ugly implementation detail visible. I think it's better
(although the .NET Framework naming rules say something different) to use
pascal case for everything which is publically visible (including
namespaces, classes, methods, properties, fields, and method parameters)
and maybe use camel case internally.
Just my 2 Euro cents...
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
MS suggest camel for Protected instance field
and Pascal for Public instance field
Do you think they meant Friend, Private and Protected as protected
instances?
"Mitchell S. Honnert" <ne**@REMhonnertOVE.com> wrote in message
news:uL**************@TK2MSFTNGP09.phx.gbl... One would use camelCase on variables to denote *instantiation*.
Only if one wanted to flout the Microsoft naming standard. ;-)
You use PascalCase? Wow... if I had my method variables named all
PascalCase I wouldn't be able to tell what was a method or static property
or whatever of an imported namespace or property of the class or global
function or sub in a global VB module. Is MsgBox() a variable or an
array... oh wait it's a method.... wait... is it? What am I doing?
Have a look at that link I included before. There's a pretty basic set of
rules for method and property naming that, as far as I can tell, would
alleviate any problems you're talking about. For example, you'd be able
to tell that EnrollCustomer was a method and that CustomerNum was a
property just by the names themselves. If you use the convention of using
verbs in your method names, you don't need to mess around with casing to
make these distinctions.
I personally would be so confused. Do you actually use PascalCase for
method variables??? Wow that is truly utterly horrible. I would shoot
myself if I had to maintain your code.
Microsoft doesn't take a stand on whether to use PascalCase for method
variables. (At least, not that I've found.)
MS on the link http://msdn.microsoft.com/library/de...tionstyles.asp
suggest camel for Parameter and for Protected instance field
and Pascal for Public instance field
Do you think they meant Friend, Private and Protected as protected
instances?
> 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.
What about Public variables
If there are any do you think it makes sense to make them PascalCase as MS
suggests? This thread has been closed and replies have been disabled. Please start a new discussion. |
