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,pic,
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 enthusiastically 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.Substring() 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**************@TK2MSFTNGP11.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,pic,
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 enthusiastically 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.Substring() 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**************@tk2msftngp13.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**************@TK2MSFTNGP11.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,pic, 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 enthusiastically 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.Substring() 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 selfdocumentating
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,pic,
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 enthusiastically 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.Substring() 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.com/team/vb/VBSampleGuidelines.htm>

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

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

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

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

SharpDevelop C# Coding Style Guide 0.3
<http://www.icsharpcode.net/TechNotes/SharpDevelopCodingStyle03.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 "professional" 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**************@TK2MSFTNGP11.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,pic,
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 enthusiastically 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.Substring() 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*********@btopenworld.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*********@btopenworld.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*********@btopenworld.com> wrote in message
news:ca**********@titan.btinternet.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 "professional" 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**************@TK2MSFTNGP11.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,pic, 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 enthusiastically 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.Substring() 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 think this notation is someone's personal brainchild

--

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

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*********@btopenworld.com> wrote in message
news:ca**********@titan.btinternet.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 "professional" 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**************@TK2MSFTNGP11.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,pic, 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 enthusiastically 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.Substring()

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

Well, as long as its consistent even alien conventions are useful. It's easy
maintaining someone else's applications as long as the coding style is
*consistent* throughout the project.

Having said that, and being a big believer in consistency, I'm worried that
*my* conventions will at some point clash with the larger .NET universe and
it will become harder and harder for me to stick with them. I'm lucky right
now because my partners believe as I do... and many other coders who
contribute code and controls to places such as CodeProject or GotDotNet use
very VB3/4/5/6-esque conventions. But at some point in the future I see the
entire style meeting its death.
"One Handed Man ( OHM - Terry Burns )" <news.microsoft.com> wrote in message
news:e$**************@tk2msftngp13.phx.gbl...

I think this notation is someone's personal brainchild

--

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

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*********@btopenworld.com> wrote in message
news:ca**********@titan.btinternet.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 "professional" 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**************@TK2MSFTNGP11.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,pic,

> 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 enthusiastically 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.Substring() 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, any method is better than no method, because at least if
you have a method one can then criticise its patterns and processes (
something to point at so to speak. )

I'm not sure if there is a globally accepted coding convention for .NET
really, but MS have their own view, although so do others.

The one convention I will not use is the m_ , it drives me insane having to
do underscores all the time.

--

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

Well, as long as its consistent even alien conventions are useful. It's easy maintaining someone else's applications as long as the coding style is
*consistent* throughout the project.

Having said that, and being a big believer in consistency, I'm worried that *my* conventions will at some point clash with the larger .NET universe and it will become harder and harder for me to stick with them. I'm lucky right now because my partners believe as I do... and many other coders who
contribute code and controls to places such as CodeProject or GotDotNet use very VB3/4/5/6-esque conventions. But at some point in the future I see the entire style meeting its death.
"One Handed Man ( OHM - Terry Burns )" <news.microsoft.com> wrote in message news:e$**************@tk2msftngp13.phx.gbl...

I think this notation is someone's personal brainchild

--

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

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*********@btopenworld.com> wrote in message
news:ca**********@titan.btinternet.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 "professional" 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**************@TK2MSFTNGP11.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,pic,
> > 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 enthusiastically 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.Substring()

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

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

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

Some people used 'f' to denote function procedures...

;-)

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

[The Grim Reaper]

I didn't realise about lpsz and p prefixes in C++ until a year ago - I've
somehow managed to carefully avoid all forms of C over the years :D (I
started on Amigas with Blitz Basic and AmigaDos... hehe)

I agree with the m_ thing - another thing I do that really annoys people is
use Verdana in the IDE... (I can tell you lot don't like me already...
lol) - and underscores become unreadable in tight coded sections. Still -
at least I don't use Times New Roman...

It's hard to change a convention once you get used to it. After using the
one I use for 4 years now, reading other people's code is slow and sometimes
error-prone to me. I'm changing jobs back to full time VB/.NET programming
soon, so I'll no doubt be learning a whole new convention to fit in with the
company I'll hopefully join!!
_______________________________
The Grimy Raper

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

I agree with you, any method is better than no method, because at least if
you have a method one can then criticise its patterns and processes (
something to point at so to speak. )

I'm not sure if there is a globally accepted coding convention for .NET
really, but MS have their own view, although so do others.

The one convention I will not use is the m_ , it drives me insane having to do underscores all the time.

--

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

Well, as long as its consistent even alien conventions are useful. It's easy

maintaining someone else's applications as long as the coding style is
*consistent* throughout the project.

Having said that, and being a big believer in consistency, I'm worried

that

*my* conventions will at some point clash with the larger .NET universe

and

it will become harder and harder for me to stick with them. I'm lucky

right

now because my partners believe as I do... and many other coders who
contribute code and controls to places such as CodeProject or GotDotNet

use

very VB3/4/5/6-esque conventions. But at some point in the future I see

the

entire style meeting its death.
"One Handed Man ( OHM - Terry Burns )" <news.microsoft.com> wrote in

message

news:e$**************@tk2msftngp13.phx.gbl...

I think this notation is someone's personal brainchild

--

OHM ( Terry Burns )
. . . One-Handed-Man . . .
<cm****@nospam.com> wrote in message
news:eh**************@tk2msftngp13.phx.gbl...
> 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*********@btopenworld.com> wrote in message
> news:ca**********@titan.btinternet.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 "professional" 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**************@TK2MSFTNGP11.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,pic,
> > > 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 enthusiastically 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.Substring() 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.*
> > >
> > >
> >
> >
>
>

[PseudoBill]

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

Thanks - I thought I was the only one. I use it for exactly the same
reason - I want to be reminded of the types I'm dealing with on a
glance (not a right-click or cursor-hover). I also want to know the
scope at a glance. These advantages will keep hungarian around for
some time I think - I haven't seen any good arguments against it,
although a lot are against it.
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com

[bob_spear]

I've encountered some books in Oracle PL/SQL programming in which v is the
standard prefix for a variable, especially when distinguishing a program
variable from a field name in the database.

"cm****@nospam.com" wrote:

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*********@btopenworld.com> wrote in message
news:ca**********@titan.btinternet.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 "professional" 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**************@TK2MSFTNGP11.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,pic, 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 enthusiastically 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.Substring() 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.*

[bob_spear]

I author computer programming textbooks and teach VB .NET. The use of a
prefix to identify the class of an object or the scope and data tyope of a
variable is quite valuable to programmers, especially beginning programmers.
The demise of this practice is a cardinal error, IMHO.

"cm****@nospam.com" wrote:

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,pic,
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 enthusiastically 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.Substring() 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 \)]

Well, I can see the merits of Hungarian Notation, however, the ECMA
standards for C# do not support this. Microsoft does not seem to want to be
drawn on this point. I have decided to go with the ECMA standards and to be
honest, I have not noticed any appreciable difference in how readable my
code is, in fact if anything it's easier to read because Im not constantly
distracted by prefixes.

IMHO. I think if you write well structured code, the appropriate use of
camelCase and PascalCase as laid out by the ECMA standards is fine.
--

OHM ( Terry Burns )
. . . One-Handed-Man . . .
If U Need My Email ,Ask Me

Time flies when you don't know what you're doing

"bob_spear" <bo******@discussions.microsoft.com> wrote in message
news:BC**********************************@microsof t.com...

I author computer programming textbooks and teach VB .NET. The use of a
prefix to identify the class of an object or the scope and data tyope of a
variable is quite valuable to programmers, especially beginning programmers. The demise of this practice is a cardinal error, IMHO.

"cm****@nospam.com" wrote:

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,pic, 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 enthusiastically 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.Substring() 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.*

[KevDev]

I agree. While type (or more correctly semantics) can be implied by a
descriptive variable name, implying scope is difficult without prefixes.
Using m_ for private member variables (or fields as they are known in
.NET) is extremely useful.

Although C# provides the use of 'this.' to disambiguate where compiler
confusion could arise, surely it is far better to disambiguate using a
prefix such as 'm_' so that someone reading the code can disambiguate
wherever it occurs. After all, what's obvious to the compiler may not be
obvious to mere mortals!
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!