Letting go of Hungarian Notation

[Guest]

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

 

[Guest]

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

 

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

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=#YF7Ng3uCHA.572@TK2MSFTNGP12>

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

Design Guidelines for Class Library Developers
<http://msdn.microsoft.com/library/d...ef/html/cpconnetframeworkdesignguidelines.asp>

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

 

[Herfried K. Wagner [MVP]]

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

 

[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

 

[Herfried K. Wagner [MVP]]

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.

 

[Guest]

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

 

[Guest]

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

 

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

I think this notation is someone's personal brainchild

 

[Guest]

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

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.

 

[Herfried K. Wagner [MVP]]

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

;-)

 

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

 

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

 

[Guest]

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.

 

[Guest]

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.

 

[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

 

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