Re: How to name variables in a program?

Martijn wrote:

> > Having a strong convention for naming your variables in your program
> > is an important issue often overlooked.
> > Can anyone point me to a good source on the web dealing with this
> > issue?
>
> Ever since I picked up the book Windows programming book by Petzold, I
have
> been using something called "Hungarian notation":
> http://en.wikipedia.org/wiki/Hungarian_notation

> Although it is by no means a guide on picking good names for your
variables,
> this convention works with prefixes to indicate variable type.

There's a long list of various reasons why that's wrong. Use Google and
Google Groups for "Hungarian notation" for the bloggage of many an engineer
coming to realize this. Unfortunately, here comes another one, because below
here you point to one of the biggest and best examples why HN is wrong.

> - every structure I define, I trail with a comment indicating the
> hungarian code

An early MS editor, Programmer's WorkBench, could not browse code. You could
not click on an indentifier and hit "Go to Definition". So, to enable a kind
of browsing, you could drag-select the wart, such as msgFoo for MSG, and
invoke Help. It would take you to the online help for MSG.

This minor editor feature is a major reason all the early MS code used HN.
Modern MS code is drifting away from it.

> - prefix global variables with g_

No prob. I forgot "prefix members with m_". But these indicate storage, not
type, so they are not HN.

> - prefix pointers with lp (this stands for "long pointer" and is still
> reminiscent of the 16 bit Windows days)

That is a primary example why Hungarian Notation wrong. VC++ supports
libraries that use the unpronouncable name LPCTSTR, meaning Long Pointer to
a Typed Constant STRing.

The biggest and most commonly cited reason HN is wrong is this: When you
refactor, if a type changes, you must either hunt down and change every
instance of the HN and change it, or you must live a lie, and forsake HN's
slim capacity to self-document.

That problem has bitten Microsoft. My version of VC++ can't produce 16-bit
programs. If it produced a 64-bit programs, the L would in fact be a Short,
because 64-bit chips support various 32- and 48-bit memory models, where
32-bit short pointers can peacibly coexist with various 48-bit segmented
pointers, and with 64-bit super pointers.

So the L in LPCTSTR lives a lie. At refactor time, MS cannot search and
replace every instance of LPCTSTR in the world. MS header files are infested
with this nonsense. The beloved DWORD is no longer a Double WORD; on a
modern CPU it is a WORD.

And POINT_TYPED_STRING would have been pronouncable.

--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand


.

Relevant Pages

  • Re: How to name variables in a program?
    ... Phlip wrote: ... >> this convention works with prefixes to indicate variable type. ... > This minor editor feature is a major reason all the early MS code used HN. ... > pointers, ...
    (comp.programming)
  • Re: How to name variables in a program?
    ... >> Ever since I picked up the book Windows programming book by Petzold, ... > libraries that use the unpronouncable name LPCTSTR, ... > various 48-bit segmented pointers, ... of the less ambiguous DWORD. ...
    (comp.programming)
  • Re: Question on Joining of list
    ... k are indices, p, q, r are pointers, s, t are strings and x, y, z are ... Only by convention (even-K&R-v1 C required explicit declarations ...
    (comp.lang.python)
  • Re: SYSTEMTIME and Conversion
    ... I remember getting very confused by pointers and pointers to pointers and ... "Kerstin Pirrung" wrote: ... > GetDateFormat(NULL, NULL, p_stTime, (LPCTSTR) csDateformat, tcDatHelp,40); ...
    (microsoft.public.pocketpc.developer)
  • Re: tree data structure: incomplete type error
    ... store a number of links to its children. ... You can declare pointers to structures of as ... yet incomplete types, but that is all -- you won't be ale to do ... A better convention is H_LIST. ...
    (comp.lang.c)