Re: How to name variables in a program?

Hi Phlip,

First of all thank you for your lengthy response. Naturally I don't agree
on everey point ;)

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

I have read this articles, and agree with only some of their points. The
fact is that almost all my variables are local, only rarely do I use
globals, so I have never had a problem of refactoring that I couldn't solve
with search/replace. And so far it has worked very well for me, so I don't
have any reason to abandon it - in fact, it has become second nature
throughout the years.

When working with teams that have their own naming conventions (and trust
me, they always differ from one-another, yet another reason why I have not
adopted one of those) I adapt and use that.

> 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

[snipped]

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

[nitpick] I thought is was Long Pointer to ConsTant STRing [/nitpick] But
indeed I disagree with you on this one. But not because it uses HN, but
because it uses it in the wrong place.

To clarify this point and the one I tried to make about structures:

typedef struct tagMYSTRUCT /* mys */
{
...
} MYSTRUCT;

(Some prefer _MYSTRUCT and some don't typedef structures at all)
What I absolutely do not do:

typedef struct tagMYSTRUCT /* mys */
{
...
} MYSTRUCT, *LPMYSTRUCT;
^^^^^^^^^^^

The latter I believe to be one of the major faults in using HN. Firstly, it
can be considered as code obfuscation (and some do), secondly, if you are
writing libraries, you are "forcing" others to use it too.

[snipped some more]

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

Remember that the size of an integer has also changed throughout the years.
And if we go way back, even the size of "long" has changed, if I am not
mistaken. VC++ would produce 64 bit code, longs should still be longs,
regardless of how much storage they indicate. This in fact is the advantage
of the less ambiguous DWORD.

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

When the definition of a double word is "two words", being four bytes, I
don't agree with that last statement. The implementation may change, but a
DWORD should hold four bytes. Whether this may be enough to hold certain
information it is currently holding (in some structures they are general
purpose members, containing anything ranging from an integer to a pointer),
the definition of a DWORD (being four bytes, being 32 bits) is entirely
unambiguous.

The problem with the LPCTSTR is a known one. That's why I stated the
legacy-ness (if that is a word) of the "lp" in general, because pointers in
Win32 (as far as I know) are always 32-bit, so the "l" is entirely redundant
(and as you correctly stated, entirely wrong in the future).

But maybe I should just browse those documents you refer to. Or maybe this
whole HN thing should just blow up in my face :) Right now it is working
for me, and for me allows me to structurize my naming convetion, and the
most important thing of any naming convention is that it is consistent (this
is more of a note to the OP).

Greets,

--
Martijn
http://www.sereneconcepts.nl


.

Relevant Pages

  • Re: How to name variables in a program?
    ... > this convention works with prefixes to indicate variable type. ... That is a primary example why Hungarian Notation wrong. ... pointers, ... So the L in LPCTSTR lives a lie. ...
    (comp.programming)
  • Re: Visual C++6, MFC project to Visual Studio 2005 MFC
    ... MFC project to Visual Studio 2005 MFC and ... I have a lot of warnings. ... getting these when you cast handles or pointers to int, DWORD, long, UINT, or INT, your ...
    (microsoft.public.vc.mfc)
  • Re: reference
    ... DWORD* is equal to LPDWORD ... why microsoft need make more confusion and create another type ... pointers. ...
    (microsoft.public.vc.language)
  • RE: native exception inside mscoree1_0.dll. Root cause?!
    ... I've checked the P/Invoke code ... memory, ... > DWORD dwSize; ... > Note it has couple pointers in it which is not supported by CF ...
    (microsoft.public.dotnet.framework.compactframework)
  • 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)