I finally did it-- hungarian notation

[CMM]

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).

 

[CMM]

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]

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]

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]

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]

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.

 

[Steve Long]

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

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/d...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

: > 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.

 

[Steve Long]

That would be really annoying.

 

[Mitchell S. Honnert]

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

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

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/d...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

: > 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.

 

[Mitchell S. Honnert]

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/d...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]

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

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

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/d...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


: > 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.

 

[CMM]

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?

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

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

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/d...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


: > 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.

 

[Herfried K. Wagner [MVP]]

Mitchell,

Herfried, I don't read German, so I haven't read your article, but I do
have a question about your first summarized point...
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...

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]

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

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

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


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/d...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


: > 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.

 

[Steve Long]

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?

 

[Mitchell S. Honnert]

Do you have a particular link that says to use camelCase for variables

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/d...s/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

 

[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]

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

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?

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

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


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/d...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


: > 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.