Letting go of Hungarian Notation

Just seeking some advice (or solace)...
Am I the only who's having trouble letting go of notation? Having extensive
experience in C++ years ago (both before I jumped into VB3 in college and at
various times during my VB career), I welcomed the "richly-typed" .NET
framework. But, after almost *two years* of "giving it a chance," I still
insist that using notation for the "common" (mostly value-types) types
(string, integer, boolean, etc.) is extremely beneficial. I can instantly
see that I'm dealing with a declared variable in my procedure rather than a
property or some framework object. Even using "o" to denote other
instantiated (reference) objects is beneficial because I can instantly see
that I'm dealing with an actual instantiated object rather than some
"Shared" Class.

Here are some of the standards I've adopted after almost two years of
experience in .NET.
1) Use all the old VB standards for intrinsic types (s,i,b,dt, etc.-- yeah I
dropped the 3 letter notation for simple types years ago) with some new
additions for commonly used Framework objects (sb for StringBuilder, for
instance).
2) "o" for all other lesser used framework types and instantiated objects.
3) All the old VB notations for the most common controls (lbl,btn,txt,pi c,
etc.). Derived controls and fancy custom controls get noted according to
their purpose or roots (i.e. "fancy buttons" still get the "btn" notation).
4) "m_" or the more c#-like "_" to denote module-level variables.
5) "g_" for global variables.
6) All Caps for global constants.
7) I even tried to keep notation out of my procedure parameters... but
decided I liked those too (although I agree that they're ugly when seen
through intellisense).

So on and so forth. I should also note that I'm not a "resistor". ... I tried
very hard to be open-minded. I've enthusiasticall y accepted a lot of the
..NET conventions (structured error handling, options strict on, using
framework objects as oppossed to the legacy VB equivalents (where
appropriate... i.e. Mid/Left/Right still beats String.Substrin g() anyday if
only because of the graceful error handling )).

Any comments, advice? (P.S. I'm not an old fogey (28).... but I have been
coding since I was 13. Maybe that's the problem!) *Sigh.*

[One Handed Man \( OHM - Terry Burns \)]

I agree with you.

However, I am too lazy to prefix identifiers with s, i etc and rely more on
appropriately commented and well written code to assist in maintainability
and readability.

Therefore I tend not to use prefixes except with controls such as btn, lbl
as you do. I do allways use upper case for constants though
--

OHM ( Terry Burns )
. . . One-Handed-Man . . .
<cm****@nospam. com> wrote in message
news:um******** ******@TK2MSFTN GP11.phx.gbl...

Just seeking some advice (or solace)...
Am I the only who's having trouble letting go of notation? Having extensive experience in C++ years ago (both before I jumped into VB3 in college and at various times during my VB career), I welcomed the "richly-typed" .NET
framework. But, after almost *two years* of "giving it a chance," I still
insist that using notation for the "common" (mostly value-types) types
(string, integer, boolean, etc.) is extremely beneficial. I can instantly
see that I'm dealing with a declared variable in my procedure rather than a property or some framework object. Even using "o" to denote other
instantiated (reference) objects is beneficial because I can instantly see
that I'm dealing with an actual instantiated object rather than some
"Shared" Class.

Here are some of the standards I've adopted after almost two years of
experience in .NET.
1) Use all the old VB standards for intrinsic types (s,i,b,dt, etc.-- yeah I dropped the 3 letter notation for simple types years ago) with some new
additions for commonly used Framework objects (sb for StringBuilder, for
instance).
2) "o" for all other lesser used framework types and instantiated objects.
3) All the old VB notations for the most common controls (lbl,btn,txt,pi c,
etc.). Derived controls and fancy custom controls get noted according to
their purpose or roots (i.e. "fancy buttons" still get the "btn" notation). 4) "m_" or the more c#-like "_" to denote module-level variables.
5) "g_" for global variables.
6) All Caps for global constants.
7) I even tried to keep notation out of my procedure parameters... but
decided I liked those too (although I agree that they're ugly when seen
through intellisense).

So on and so forth. I should also note that I'm not a "resistor". ... I tried very hard to be open-minded. I've enthusiasticall y accepted a lot of the
.NET conventions (structured error handling, options strict on, using
framework objects as oppossed to the legacy VB equivalents (where
appropriate... i.e. Mid/Left/Right still beats String.Substrin g() anyday if only because of the graceful error handling )).

Any comments, advice? (P.S. I'm not an old fogey (28).... but I have been
coding since I was 13. Maybe that's the problem!) *Sigh.*

(in jest... sort of) I dislike overly commented code too!.. It makes it
harder to read. I once had a partner who commented his code as such (no
joke!):

'if x is greater than y
If x > y then
....

He would litter these gems and then some all over the place. It made
maintaining his code an absolute nightmare.

:-)

"One Handed Man ( OHM - Terry Burns )" <news.microsoft .com> wrote in message
news:uo******** ******@tk2msftn gp13.phx.gbl...

I agree with you.

However, I am too lazy to prefix identifiers with s, i etc and rely more on appropriately commented and well written code to assist in maintainability
and readability.

Therefore I tend not to use prefixes except with controls such as btn, lbl
as you do. I do allways use upper case for constants though
--

OHM ( Terry Burns )
. . . One-Handed-Man . . .
<cm****@nospam. com> wrote in message
news:um******** ******@TK2MSFTN GP11.phx.gbl...

Just seeking some advice (or solace)...
Am I the only who's having trouble letting go of notation? Having extensive

experience in C++ years ago (both before I jumped into VB3 in college and at

various times during my VB career), I welcomed the "richly-typed" .NET
framework. But, after almost *two years* of "giving it a chance," I

still insist that using notation for the "common" (mostly value-types) types
(string, integer, boolean, etc.) is extremely beneficial. I can instantly see that I'm dealing with a declared variable in my procedure rather than a

property or some framework object. Even using "o" to denote other
instantiated (reference) objects is beneficial because I can instantly

see that I'm dealing with an actual instantiated object rather than some
"Shared" Class.

Here are some of the standards I've adopted after almost two years of
experience in .NET.
1) Use all the old VB standards for intrinsic types (s,i,b,dt, etc.-- yeah I

dropped the 3 letter notation for simple types years ago) with some new
additions for commonly used Framework objects (sb for StringBuilder, for
instance).
2) "o" for all other lesser used framework types and instantiated

objects. 3) All the old VB notations for the most common controls (lbl,btn,txt,pi c, etc.). Derived controls and fancy custom controls get noted according to
their purpose or roots (i.e. "fancy buttons" still get the "btn"

notation).

4) "m_" or the more c#-like "_" to denote module-level variables.
5) "g_" for global variables.
6) All Caps for global constants.
7) I even tried to keep notation out of my procedure parameters... but
decided I liked those too (although I agree that they're ugly when seen
through intellisense).

So on and so forth. I should also note that I'm not a "resistor". ... I

tried

very hard to be open-minded. I've enthusiasticall y accepted a lot of the
.NET conventions (structured error handling, options strict on, using
framework objects as oppossed to the legacy VB equivalents (where
appropriate... i.e. Mid/Left/Right still beats String.Substrin g() anyday

if

only because of the graceful error handling )).

Any comments, advice? (P.S. I'm not an old fogey (28).... but I have been coding since I was 13. Maybe that's the problem!) *Sigh.*

[Cor Ligthert]

Hi,

'if x is greater than y
If x > y then
He would litter these gems and then some all over the place. It made
maintaining his code an absolute nightmare.

With this you give direct an answer, Cobol was the first selfdocumentati ng
program language, when you saw old Fortran programmers use it, it became
direct a nightmare.

VB has the possibility to use names which makes it very good reach that
extra in the language of Cobol above most other languages, do it not use as
a Fortran or C type language, which needs often a lot of extra documentation
rows as the one you see above.

VB is case insensetive, the nicest would be in my opinion to use your own
natural language styles for it. (Which are very different in the world by
the way).

I know I kicking to a lot of programmers, however this are my thoughts, not
how I am doing it.

Cor

[Herfried K. Wagner [MVP]]

* <cm****@nospam. com> scripsit:

Am I the only who's having trouble letting go of notation? Having extensive
experience in C++ years ago (both before I jumped into VB3 in college and at
various times during my VB career), I welcomed the "richly-typed" .NET
framework. But, after almost *two years* of "giving it a chance," I still
insist that using notation for the "common" (mostly value-types) types
(string, integer, boolean, etc.) is extremely beneficial. I can instantly
see that I'm dealing with a declared variable in my procedure rather than a
property or some framework object. Even using "o" to denote other
instantiated (reference) objects is beneficial because I can instantly see
that I'm dealing with an actual instantiated object rather than some
"Shared" Class.

Here are some of the standards I've adopted after almost two years of
experience in .NET.
1) Use all the old VB standards for intrinsic types (s,i,b,dt, etc.-- yeah I
dropped the 3 letter notation for simple types years ago) with some new
additions for commonly used Framework objects (sb for StringBuilder, for
instance).
2) "o" for all other lesser used framework types and instantiated objects.
3) All the old VB notations for the most common controls (lbl,btn,txt,pi c,
etc.). Derived controls and fancy custom controls get noted according to
their purpose or roots (i.e. "fancy buttons" still get the "btn" notation).
4) "m_" or the more c#-like "_" to denote module-level variables.
5) "g_" for global variables.
OK, that's all nice, IMO.
6) All Caps for global constants.
I hate that. I only use "all caps" for API constants that are directly
taken from the corresponding header files. In all other cases I prefer
Pascal Case for constants.
7) I even tried to keep notation out of my procedure parameters... but
decided I liked those too (although I agree that they're ugly when seen
through intellisense).
Personally, I don't use these prefixes for parameters any more, but as a
VB.NET programmier, I use Pascal Case there too. I don't use Camel
Case.
So on and so forth. I should also note that I'm not a "resistor". ... I tried
very hard to be open-minded. I've enthusiasticall y accepted a lot of the
.NET conventions (structured error handling, options strict on, using
framework objects as oppossed to the legacy VB equivalents (where
appropriate... i.e. Mid/Left/Right still beats String.Substrin g() anyday if
only because of the graceful error handling )).

There are no fixed rules, there are only recommendations .

My FAQ:

Naming Guidelines and Code Conventions:

Visual Basic .NET Sample Guidelines
<http://www.gotdotnet.c om/team/vb/VBSampleGuideli nes.htm>

Naming Conventions for .NET / C# Projects
<http://www.akadia.com/services/naming_conventi ons.html>

Sheep .Net Naming and Style Convention: Introduction and References
<http://www.google.de/groups?selm=%23 YF7Ng3uCHA.572% 40TK2MSFTNGP12>

Naming Guidelines
<http://msdn.microsoft. com/library/en-us/cpgenref/html/cpconnamingguid elines.asp>

Design Guidelines for Class Library Developers
<http://msdn.microsoft. com/library/default.asp?url =/library/en-us/cpgenref/html/cpconnetframewo rkdesignguideli nes.asp>

SharpDevelop C# Coding Style Guide 0.3
<http://www.icsharpcode .net/TechNotes/SharpDevelopCod ingStyle03.pdf>

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Herfried K. Wagner [MVP]]

* <cm****@nospam. com> scripsit:

(in jest... sort of) I dislike overly commented code too!.. It makes it
harder to read. I once had a partner who commented his code as such (no
joke!):

'if x is greater than y
If x > y then
...

He would litter these gems and then some all over the place. It made
maintaining his code an absolute nightmare.

LOL -- I never liked this sort of comments too.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[The Grim Reaper]

Hmmmm.. none of your notations seem to match the way I was taught :S Most
bizarre!!

I started programming at 12ish (25 now), and when I moved to VB at 16, I was
taught Hungarian notation. I later got my first "profession al" job at 19,
and the company I worked for had a strict standard which for some unknown
reason I have followed ever since...

1) Module variables prefixed mv
2) Class variables prefixed cv (although I usually just use mv...)
3) "Normal" variables prefixed v
4) Variables that have been passed into a procedure prefixed p (Function
Foo(pName as string, pType as... etc)
5) All the usual txt, lbl, dlg for controls, except it's cmd for command
buttons ( :S !!)
6) Global vars prefixed gv
7) Constants the same as above - gc or mc - not in capitals

God only knows why I've stuck to this notation (fear of going through a
billion lines or source code to change it all I suppose :)) ) Does anyone
know where this form of notation might have originated??
_______________ _______________ _____
The Grim Reaper

<cm****@nospam. com> wrote in message
news:um******** ******@TK2MSFTN GP11.phx.gbl...

Just seeking some advice (or solace)...
Am I the only who's having trouble letting go of notation? Having extensive experience in C++ years ago (both before I jumped into VB3 in college and at various times during my VB career), I welcomed the "richly-typed" .NET
framework. But, after almost *two years* of "giving it a chance," I still
insist that using notation for the "common" (mostly value-types) types
(string, integer, boolean, etc.) is extremely beneficial. I can instantly
see that I'm dealing with a declared variable in my procedure rather than a property or some framework object. Even using "o" to denote other
instantiated (reference) objects is beneficial because I can instantly see
that I'm dealing with an actual instantiated object rather than some
"Shared" Class.

Here are some of the standards I've adopted after almost two years of
experience in .NET.
1) Use all the old VB standards for intrinsic types (s,i,b,dt, etc.-- yeah I dropped the 3 letter notation for simple types years ago) with some new
additions for commonly used Framework objects (sb for StringBuilder, for
instance).
2) "o" for all other lesser used framework types and instantiated objects.
3) All the old VB notations for the most common controls (lbl,btn,txt,pi c,
etc.). Derived controls and fancy custom controls get noted according to
their purpose or roots (i.e. "fancy buttons" still get the "btn" notation). 4) "m_" or the more c#-like "_" to denote module-level variables.
5) "g_" for global variables.
6) All Caps for global constants.
7) I even tried to keep notation out of my procedure parameters... but
decided I liked those too (although I agree that they're ugly when seen
through intellisense).

So on and so forth. I should also note that I'm not a "resistor". ... I tried very hard to be open-minded. I've enthusiasticall y accepted a lot of the
.NET conventions (structured error handling, options strict on, using
framework objects as oppossed to the legacy VB equivalents (where
appropriate... i.e. Mid/Left/Right still beats String.Substrin g() anyday if only because of the graceful error handling )).

Any comments, advice? (P.S. I'm not an old fogey (28).... but I have been
coding since I was 13. Maybe that's the problem!) *Sigh.*

[Herfried K. Wagner [MVP]]

* "The Grim Reaper" <gr*********@bt openworld.com> scripsit:

5) All the usual txt, lbl, dlg for controls, except it's cmd for command
buttons ( :S !!)

Mhm... Seems to be a VB Classic convention where 'btn' was rarely used.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

Really? I've never ever seen his sort of conventions. Neither in VB nor
C/C++ (though some of it does seem familiar). Although up until .NET I used
cmd for buttons (and sometimes still do until I catch myself).

"Herfried K. Wagner [MVP]" <hi************ ***@gmx.at> wrote in message
news:2j******** ****@uni-berlin.de...

* "The Grim Reaper" <gr*********@bt openworld.com> scripsit:

5) All the usual txt, lbl, dlg for controls, except it's cmd for command buttons ( :S !!)

Mhm... Seems to be a VB Classic convention where 'btn' was rarely used.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

I've never ever quite seen that notation I don't think. Maybe a Pascal
derivative? I dunno. So all your variables are noted with "v"... hmm...
that's a "Variant" to me. Classically the notation I use (and what I always
thought was a common VB standard) is a descendent of the classic C
conventions (str, int, bln, etc). I've worked with people that use p to
denote proc parameters in VB but that annoys me (p is a pointer in C++).

"The Grim Reaper" <gr*********@bt openworld.com> wrote in message
news:ca******** **@titan.btinte rnet.com...

Hmmmm.. none of your notations seem to match the way I was taught :S Most
bizarre!!

I started programming at 12ish (25 now), and when I moved to VB at 16, I was taught Hungarian notation. I later got my first "profession al" job at 19,
and the company I worked for had a strict standard which for some unknown
reason I have followed ever since...

1) Module variables prefixed mv
2) Class variables prefixed cv (although I usually just use mv...)
3) "Normal" variables prefixed v
4) Variables that have been passed into a procedure prefixed p (Function
Foo(pName as string, pType as... etc)
5) All the usual txt, lbl, dlg for controls, except it's cmd for command
buttons ( :S !!)
6) Global vars prefixed gv
7) Constants the same as above - gc or mc - not in capitals

God only knows why I've stuck to this notation (fear of going through a
billion lines or source code to change it all I suppose :)) ) Does anyone
know where this form of notation might have originated??
_______________ _______________ _____
The Grim Reaper

<cm****@nospam. com> wrote in message
news:um******** ******@TK2MSFTN GP11.phx.gbl...

Just seeking some advice (or solace)...
Am I the only who's having trouble letting go of notation? Having extensive

experience in C++ years ago (both before I jumped into VB3 in college and at

various times during my VB career), I welcomed the "richly-typed" .NET
framework. But, after almost *two years* of "giving it a chance," I

still insist that using notation for the "common" (mostly value-types) types
(string, integer, boolean, etc.) is extremely beneficial. I can instantly see that I'm dealing with a declared variable in my procedure rather than a

property or some framework object. Even using "o" to denote other
instantiated (reference) objects is beneficial because I can instantly

see that I'm dealing with an actual instantiated object rather than some
"Shared" Class.

Here are some of the standards I've adopted after almost two years of
experience in .NET.
1) Use all the old VB standards for intrinsic types (s,i,b,dt, etc.-- yeah I

dropped the 3 letter notation for simple types years ago) with some new
additions for commonly used Framework objects (sb for StringBuilder, for
instance).
2) "o" for all other lesser used framework types and instantiated

objects. 3) All the old VB notations for the most common controls (lbl,btn,txt,pi c, etc.). Derived controls and fancy custom controls get noted according to
their purpose or roots (i.e. "fancy buttons" still get the "btn"

notation).

4) "m_" or the more c#-like "_" to denote module-level variables.
5) "g_" for global variables.
6) All Caps for global constants.
7) I even tried to keep notation out of my procedure parameters... but
decided I liked those too (although I agree that they're ugly when seen
through intellisense).

So on and so forth. I should also note that I'm not a "resistor". ... I

tried

very hard to be open-minded. I've enthusiasticall y accepted a lot of the
.NET conventions (structured error handling, options strict on, using
framework objects as oppossed to the legacy VB equivalents (where
appropriate... i.e. Mid/Left/Right still beats String.Substrin g() anyday

if

only because of the graceful error handling )).

Any comments, advice? (P.S. I'm not an old fogey (28).... but I have been coding since I was 13. Maybe that's the problem!) *Sigh.*