I finally did it-- hungarian notation

[CMM]

So after three years of working in .NET and stubbornly holding on to my old
hungarian notation practices--- I resolved to try to rid myself of the
habit. Man, I gotta say that it is liberating!!! I love it.

At first I struggled with how to name controls. I tried to keep some sort of
notation with them... but I threw that away too!!! I now name them as if
they were simply properties of the form (FirstNameLabel, etc.)... which they
ARE!... and when I reference them I use the Me keyword (as all properties of
a class should be referenced). Pure joy!

Alas, I still use "m_" to indicate private class scoped variables. It helps
to set them apart from properties and with avoiding collisions with property
names... because, well, VB is not case sensitive like C#!!! This causes
problems as in the following example:

Private firstName As String
Public Property FirstName() As String
Get
Return firstName
End Get
Set(ByVal value As String)
firstName = value
End Set
End Property

I recommend that any hold outs (you know you're out there!) give it a try.
It's like a big weight is lifted from your shoulders.

 

[Martin]

Never been to Hungary but I personally prefer to prefix all objects with a
3-character code which signifies what kind of object it is. I started doing
this in VB5 way back when but now in VB2005 it turns out to be even more
useful since I can't ask the class name of an object anymore... When I loop
through a form's control collection the first 3 characters tell me exactly
what it is.

Martin

 

[Phill W.]

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

 

[Cor Ligthert [MVP]]

Herfried,

I have forever hated the use of the underscore in any dataname.

Why not just mMyPrivate instead of m_MyPrivate?

Cor

 

[_AnonCoward]

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

 

[Herfried K. Wagner [MVP]]

Cor,

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]

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


Could you summarize the points being raised in this article for those of us
who don't read German? Thanx,


Ralf

 

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

Herfried,

I did not read your complete article.

* The first character of a word/sentence serves an important role for
word recognition. In classic typography the first letter has often
been
written in upper-case and sometimes ornamented to underline its
importance. By starting identifiers' names with a lower-case letter
while using upper-case letters inside the identifier this long
tradition
in typography is obeyed.

However this is real something special German speaking people would see. But
it is true. We by instance make in our language from more words one word by
concatenating them (you will often see me that wrong in English doing as
well). I wished that even in our language this notation we are now talking
about was used. Although now is again that we use more and more hyphens.
However who knows where.

Dutch is probably the language with the most imbecile rules and in that ten
deep sub-rules, which are changed almost every 10 years to make it more
crazy.

Cor

 

[Armin Zingler]

Herfried,

I have forever hated the use of the underscore in any dataname.

Why not just mMyPrivate instead of m_MyPrivate?

private mMember as integer
private mEmber as integer 'oops, is property, too.

public property Ember
'...
end property

public property Member
'...
end property

Doesn't work. ;-) Well, rare case but possible. Avoidable with "_" (if "_"
is not used with property names). I use the underscore for visual clarity
and for better intellisense, but I also see the drawback of "hidden"
underscores for the last declaration if the "procedure separator line" is
active in the editor - but that's only one declaration and not that
important.

I use the prefix "f_". f = Field. Only for those that also have a property.
For other fields I don't use a prefix, just like I do not use "fun_" for
functions or "prop_" for properties. Fields and other members are on the
same level, thus I don't distinguish in the usage of a prefix. But I also
make exceptions, like "txt" for textboxes (or others for controls) which
are also fields.

My 2 Eurocents.


Armin

 

[Herfried K. Wagner [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.

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.

 

[Cor Ligthert [MVP]]

Herfried,

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]

Thanx. I appreciate the effort.

Ralf


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

 

[Cor Ligthert [MVP]]

Armin,

Where is that underscore situated on your keyboard. I type with ten fingers,
that underscore is so far on my keyboard, maybe is it that why I don't like
it. However it is for me probably the most that I don't like it because, as
something is underlined than it becomes not visible.

Although don't misunderstand me, your explanation makes sense. Probably I
just take another word in those cases.



Cor

 

[Herfried K. Wagner [MVP]]

Cor,

But not the use of capitals. Just pasted from Bild without any extra
meaning for the text..

Öffentliches Interesse erregt der Patent-Motorwagen mit der
100-Kilometer-Reise von Benz’ Ehefrau Bertha, die 1888 mit dem Wagen von
Mannheim nach Pforzheim fährt. Eine „Promotion-Tour“, die Benz eine Reihe
neuer Kunden verschafft. Eine Erfolgsgeschichte beginnt. Nicht nur für
Karl Benz.

There are few exceptions. "Patent-Motorwagen" could have been written as
"Patentmotorwagen". "100-Kilometer-Reise" is written this way because of
the hyphen between "100" and "Kilometer", otherwise it would have been
written as "Kilometerreise". In the last few years the english language
influenced how composed words are written ("Reservereifenablage" (correct
German) -> "Reserve-Reifen-Ablage" -> "Reserve Reifen Ablage" (incorrect
German)).

 

[Steve Long]

I hate the underscore too but I still use it a lot of the time. I'm slowing
trying to break away from to and just use the

mVarName convention for module level private variables. For local variables,
I must say, I do like the descriptive name style of:
goneBad.
I no longer feel to then need to prefix the goneBad variable with it's type
prefix however (for instance, goneBad would probably be a boolean). I guess
you call this camelback? I even use this now at the method parameter level.
It's easy and descriptive.

Steve

 

[Mitchell S. Honnert]

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]

Yeah... in fact using notation with controls is exactly THE most difficult
thing in .NET. At least with variables I had a fairly nice pattern going
on.... s,i,b, etc for simple types and o for more complex types. The
notation was really just a way for me to show *instantiation* more than
anything else... a way for me to show a piece of text in my source code was
an instantiated variable rather than a static method in an Imported .NET
framework namespace or something like that.

In the new non-hungarian notation, indication of instantiation is done using
the camelCase notation. And controls receieve no notation because they are
after all just properties of the form class and properties don't get noted.
Though they do get prefixed with the Me keyword when being accessed.

 

[CMM]

I totally agree... and your example is not rare at all. In VB at least using
m_ with the underscore is practically a necessity because of VB's
case-insensitivity.