I finally did it-- hungarian notation
CMM
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
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" <c...@nospam.com> wrote in message
news:%23EsQR8k...@TK2MSFTNGP10.phx.gbl...
Phill W.
news:Oj9kjglJ...@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.
Herfried K. Wagner [MVP]
> 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/>
Cor Ligthert [MVP]
I have forever hated the use of the underscore in any dataname.
Why not just mMyPrivate instead of m_MyPrivate?
Cor
_AnonCoward
"Cor Ligthert [MVP]" <notmyfi...@planet.nl> wrote in message
news:%23RIVW6m...@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.
Herfried K. Wagner [MVP]
"Cor Ligthert [MVP]" <notmyfi...@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...
_AnonCoward
"Herfried K. Wagner [MVP]" <hirf-spa...@gmx.at> wrote in message
news:uwk1C0m...@TK2MSFTNGP14.phx.gbl...
:
: "CMM" <c...@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,
Herfried K. Wagner [MVP]
> : > 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.
Cor Ligthert [MVP]
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
Herfried K. Wagner [MVP]
>> 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.
Armin Zingler
>
> I have forever hated the use of the underscore in any dataname.
>
> Why not just mMyPrivate instead of m_MyPrivate?
private mMember as integer
private mEmber as integer 'oops, is property, too.
public property Ember
'...
end property
public property Member
'...
end property
Doesn't work. ;-) Well, rare case but possible. Avoidable with "_" (if "_"
is not used with property names). I use the underscore for visual clarity
and for better intellisense, but I also see the drawback of "hidden"
underscores for the last declaration if the "procedure separator line" is
active in the editor - but that's only one declaration and not that
important.
I use the prefix "f_". f = Field. Only for those that also have a property.
For other fields I don't use a prefix, just like I do not use "fun_" for
functions or "prop_" for properties. Fields and other members are on the
same level, thus I don't distinguish in the usage of a prefix. But I also
make exceptions, like "txt" for textboxes (or others for controls) which
are also fields.
My 2 Eurocents.
Armin
Cor Ligthert [MVP]
>>>
>> 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
_AnonCoward
Ralf
"Herfried K. Wagner [MVP]" <hirf-spa...@gmx.at> wrote in message
news:uHVR$QnJGH...@TK2MSFTNGP14.phx.gbl...
: "_AnonCoward" <abc...@uvwxyz.com> schrieb:
:
Cor Ligthert [MVP]
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.n...@freenet.de> schreef in bericht
news:uX9mAunJ...@TK2MSFTNGP14.phx.gbl...
Herfried K. Wagner [MVP]
"Cor Ligthert [MVP]" <notmyfi...@planet.nl> schrieb:
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)).
Steve Long
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]" <notmyfi...@planet.nl> wrote in message
news:%23RIVW6m...@TK2MSFTNGP09.phx.gbl...
Mitchell S. Honnert
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.
says to use camelCase is for parameters. (I think there may be have been
one other variable type where they recommended camelCase, but if I remember
correctly, it was very rarely used.) So, the point you are making doesn't
appear to apply MS's naming standards.
In other words, MS never says to use camelCase for "backing field"
variables, as in the example...
>Private firstName As String
At least, it never says it on any official MS web page that I have found.
Here's where I have been looking.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnamingguidelines.asp
Is there some other reference that you are using? Do you have a particular
link that says to use camelCase for variables other than parameters? (I've
seen camelCase used inconsistently in MS's own VB.NET sample code, but this
probably has more to do with the authors of the sample code being C# people
than evidence of any particular naming standard.)
The problem I have is that MS states explicitly what naming convention to
use for Classes, Namespaces, Parameters, Methods, and Properties, but as far
as I can tell, they don't say how to name private member variables like the
private "backing field" for a property. I use a "p_" prefix to
differentiate these private member variables as those used by properties,
but this is just my convention that I use for lack of being able to find
anything definitive from MS.
Regards,
- Mitchell S. Honnert
"Herfried K. Wagner [MVP]" <hirf-spa...@gmx.at> wrote in message
news:uHVR$QnJGH...@TK2MSFTNGP14.phx.gbl...
CMM
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.
CMM
m_ with the underscore is practically a necessity because of VB's
case-insensitivity.
CMM
news:%23ENKJLo...@TK2MSFTNGP11.phx.gbl...
<snip>
> I'm slowing
> trying to break away from to and just use the
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).
CMM
news:%23zL%23KfoJ...@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.
Mitchell S. Honnert
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" <c...@nospam.com> wrote in message
news:e7$OZRpJG...@TK2MSFTNGP11.phx.gbl...
CMM
MySub(p_strSomething, p_intBlaBla)
Boy that was annoying!!!
;-)
Mitchell S. Honnert
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" <c...@nospam.com> wrote in message
news:u%23X8icpJ...@TK2MSFTNGP11.phx.gbl...
CMM
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:%23Q7J%23jpJG...@TK2MSFTNGP10.phx.gbl...
Steve Long
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:%23zL%23KfoJ...@TK2MSFTNGP11.phx.gbl...
Steve Long
"CMM" <c...@nospam.com> wrote in message
news:u%23X8icpJ...@TK2MSFTNGP11.phx.gbl...
Mitchell S. Honnert
have been stated somewhere is MS's guidelines, but I haven't found it yet.
But, in light of the fact that they say to use PascalCase for *everything*
in their spec except for parameters, I just use this style for private
variables as well.
In fact, if you name your private variable goneBad, you would be rendering
as useless the camelCase parameter naming convention. The whole point of
having only parameters be camelCase is that you can identify at-a-glance
variables that have been passed into a method. But if you dimention new
variables within the method using camelCase, you've lost this benefit.
In regards to your "GoneBad", I've adopted what seems to be a common
convention of prefixing Boolean variables with "Is" or "Has". As in,
IsClosed or HasGoneBad. Maybe that's a little too close to Hungarian
notation, but it brings a certain level of consistency to the code.
- Mitchell S. Honnert
"Steve Long" <Steve_...@NoSpam.com> wrote in message
news:eMIaPvpJ...@TK2MSFTNGP10.phx.gbl...
Mitchell S. Honnert
>method-declared variables (is that what you were stating?) is way confusing
>and messy in my opinion.
Look here...
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnamingguidelines.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" <c...@nospam.com> wrote in message
news:eSXzuqp...@TK2MSFTNGP09.phx.gbl...
CMM
> 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.
CMM
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:urGJTHqJ...@TK2MSFTNGP09.phx.gbl...
Herfried K. Wagner [MVP]
"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.
Herfried K. Wagner [MVP]
> 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.
Mitchell S. Honnert
>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" <c...@nospam.com> wrote in message
news:efwMMZqJ...@TK2MSFTNGP09.phx.gbl...
Steve Long
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]" <hirf-spa...@gmx.at> wrote in message
news:%23tpYqnq...@TK2MSFTNGP11.phx.gbl...
Mitchell S. Honnert
>> other than parameters?
> Guidelines" chapter.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconfieldusageguidelines.asp
If so, then I still hold to my assertion that Microsoft doesn't state
definitively to use camelCase for variables defined within a method.
Admittedly, the sample code uses this convention, but as we both have
pointed out, this is most likely a result of the fact that the VB.NET sample
code was written by C# developers. Nowhere do I see a plain statement by
Microsoft that says, "Use camelCase for local variables in a method."
As I've mentioned in other subthreads, using camelCase for variables defined
within a method would render the use of camelCase for parameters as useless.
So, surely this can't be what they really mean. When a programmer sees a
variable in camelCase format, they know that the only place in the Microsoft
standards where camelCase is explicitly recommended is for parameters, so
they know it must be a parameter.
"Use camelCase for parameters and PascalCase for everything else." That's
what I get out of reading the MS standards. camelCase may be messy, but
given this definition, it's so narrowly defined that it isn't a bid deal.
Mitchell S. Honnert
www.UltraID3Lib.com
"Herfried K. Wagner [MVP]" <hirf-spa...@gmx.at> wrote in message
news:%23tpYqnq...@TK2MSFTNGP11.phx.gbl...
CMM
> 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.
CMM
> 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
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" <c...@nospam.com> wrote in message
news:umL58jqJ...@TK2MSFTNGP09.phx.gbl...
CMM
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:ubMnj8qJ...@TK2MSFTNGP12.phx.gbl...
CMM
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:OrJ4fJrJ...@TK2MSFTNGP11.phx.gbl...
Mitchell S. Honnert
> 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.
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" <c...@nospam.com> wrote in message
news:%23j4OiHr...@tk2msftngp13.phx.gbl...
CMM
> 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
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.
Herfried K. Wagner [MVP]
>>> other than parameters?
>> They do so in the internal naming guidelines and in the "Field Usage
>> Guidelines" chapter.
> Herfried, am I looking in the right place?
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconfieldusageguidelines.asp
>
> If so, then I still hold to my assertion that Microsoft doesn't state
> definitively to use camelCase for variables defined within a method.
> Admittedly, the sample code uses this convention, but as we both have
> pointed out, this is most likely a result of the fact that the VB.NET
> sample code was written by C# developers. Nowhere do I see a plain
> statement by Microsoft that says, "Use camelCase for local variables in a
> method."
ACK. *I* have *never* been talking about local variables and claiming that
Microsoft recommends camel case for them.
Martin
"Phill W." <p-.a-....@o-p-e-n.a-c.u-k> wrote in message
news:drnm4n$378$1...@yarrow.open.ac.uk...
> "Martin" <x...@y.com> wrote in message
> news:Oj9kjglJ...@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
<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?
CMM
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
> nowadays uses camelCase for variables (not just VB or C# but also Java...
> obviously).
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" <c...@nospam.com> wrote in message
news:%23e374Xr...@tk2msftngp13.phx.gbl...
Martin
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" <c...@nospam.com> wrote in message
news:OgwwF4rJ...@TK2MSFTNGP14.phx.gbl...
Herfried K. Wagner [MVP]
> 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.).
CMM
"Mitchell S. Honnert" <ne...@REMhonnertOVE.com> wrote in message
> 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
> that Microsoft recommends camel case for them.
local variables because of my comments about how I could only find one
direct recommendation by MS to use camelCase (for parameters).
If you don't mind me asking, what naming convention do you use for local
variables?
- Mitchell S. Honnert
"Herfried K. Wagner [MVP]" <hirf-spa...@gmx.at> wrote in message
news:eW9LOur...@TK2MSFTNGP14.phx.gbl...
CMM
"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" <c...@nospam.com> wrote in message
news:%23k8Xges...@TK2MSFTNGP12.phx.gbl...
Mitchell S. Honnert
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" <c...@nospam.com> wrote in message
news:%23k8Xges...@TK2MSFTNGP12.phx.gbl...
Herfried K. Wagner [MVP]
"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.
CMM
> 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.
CMM
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]" <hirf-spa...@gmx.at> wrote in message
news:uxcEwssJ...@TK2MSFTNGP11.phx.gbl...
CMM
their own internal guidelines (which reference VB as well not just C#)?
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" <c...@nospam.com> wrote in message
news:uT0x2PtJ...@TK2MSFTNGP14.phx.gbl...
Cor Ligthert [MVP]
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:u6Ticfs...@TK2MSFTNGP14.phx.gbl...
Herfried K. Wagner [MVP]
>> 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...
Herfried K. Wagner [MVP]
> 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
Herfried K. Wagner [MVP]
"Cor Ligthert [MVP]" <notmyfi...@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.
CMM
> 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]" <hirf-spa...@gmx.at> wrote in message
news:%23IIxYcy...@TK2MSFTNGP15.phx.gbl...
academic
and Pascal for Public instance field
Do you think they meant Friend, Private and Protected as protected
instances?
academic
"Mitchell S. Honnert" <ne...@REMhonnertOVE.com> wrote in message
>> 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.
>
>> 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/default.asp?url=/library/en-us/cpgenref/html/cpconcapitalizationstyles.asp
suggest camel for Parameter and for Protected instance field
academic
> PascalCase for everything else, etc etc is very liberating and very
> consistent and will make for much more maintainable body of work.
>
If there are any do you think it makes sense to make them PascalCase as MS
suggests?