Re: How to name variables in a program?

Martijn wrote:

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

Your colleagues also need to refactor, so each team should agree where and
how to use HN.

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

Check.

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

The T in LPCTSTR stands for Typed (I guess) because the alternatives are
LPCWSTR for Wide strings, and LPCSTR for narrow ones. So the UNICODE flag
(which should be UTF16) controls the T.

> To clarify this point and the one I tried to make about structures:
>
> typedef struct tagMYSTRUCT /* mys */
> {
> ...
> } MYSTRUCT;

Exactly - that is the style MS, IBM, and PWB promoted. Their help system
would bond the warts to the documentation for MYSTRUCT.

I haven't checked, but I really doubt modern editors support that. The MS
header files no longer have the wart comments. These data would seem to
indicate that MS has backed down from pure HN.

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

But that's the thing. If you target portability to hardware not yet
invented, you must typedef everything and put the real types in one place.
The above could have morphed into * __far LPMYSTRUCT, if MYSTRUCTs suddenly
can only appear on the far heap.

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

Right - both the C++ implementation changes, and the hardware changes. The
real problem here is MS couldn't say LONG32, because at port time they _do_
want the number of bits to change.

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

You misunderstood. Your CPU already defines "WORD" (in silico, not in your
..h files), and it could be 16, 32, 48, or 64 bits. So the MS definition (2
bytes) collides with the CPU definition.

> But maybe I should just browse those documents you refer to.

I don't think you'l need to go farther than:

http://www.c2.com/cgi/wiki?HungarianNotation

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


.