Re: grid

I can't argue with your opinion here, but my basic rule is to try to make the code as understandable by others as I can. That include judicious use of comments and variable names that make sense. I never really bought into HN or camel case or [insert fad], but I admit that my naming includes similar things to these. You are right that its use has not been consistent in the SDK or MFC or, I'd guess, countless other programs. A lot of that comes from the desire to keep the legacy names as the SDK (or whatever) has evolved.

I think we'd find the same sort of inconsistency in any code developed by a team. For example, some on my team format their code using this style:

if (something)
{
// Something happens
}
else
{
// Something else happens
}

Where I'd do the same thing like this:

if (something) {
// Something happens
}
else {
// Something else happens
}

Just because I'd rather see more lines on the screen. Another guy on our team likes to do the same thing like this:

if (something)
{
// Something happens
}
else
{
// Something else happens
}

And I find that even more difficult to follow. However, these are all just style issues. Too many choices...

Tom

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message news:lq8t235drj4briscegvf3ap2v497ogqvvb@xxxxxxxxxx
The notation was invented in the days before there was cross-boundary prototype checking
in the C compilers (pre-ANSI C). Also, HN as originally designed did NOT include the
representation type with the name; it used the LOGICAL CONCEPT as a type, but NEVER
anything as stupid as 'dw' was used (I got this from private email from a developer who
was there when it was invented, and who was part of the Word development team where it was
used, but doesn't want his name disclosed. He says that the Windows group saw HN,
completely missed the point of it, and misapplied it uniformly everywhere. I agree with
him. As designed, it would actually have served a useful purpose. As used in Windows, it
is merely noise, and often erroneous and misleading noise. Any programmer too lazy to
look up the declaration of a variable has deeper problems that HN won't solve.)

HN should be discouraged, and the total disregard of it in C# is a significant step
forward. HN as used in Windows is a colossal step backward, confusing the concept of
interface and representation. It was a mistake. It was a misapplication of what was
probably a reasonable idea in pre-ANSI compilers, but which is irrelevant in modern
programming. Between Intellisense and the browser, it is nothing more than a waste of
space and intellectual overhead. Think of the really, really, REALLY STUPID ideas, such
as the name 'wParam' being a 32-bit or 64-bit value, or 'lParam' being a 32-bit or 64-bit
value. We will ignore the huge number of failures in the PSDK, such as VOID psz, LPCTSTR
dw, and so on that are easily findable (I found at least 30 such errors with minimal
effort, which is 30 more errors than should have been allowed to exist. It is almost as
bad as the horror of naming fields in structs with prefixes that indicate the type of the
struct, such as tmHour, tmMinute, and tmSecond, a throwback to an exceptionally poor C
compiler, the K&R compiler, that declared all field names as global names, because structs
were an afterthought. This is the same design error that gave us "." and "->" as
different operators for the same concept, field access of a structure).

Therefore, whatever purpose it might once have served, it is largely irrelevant today.
Given how poorly it is used, it should be abandoned (consider BOOL fOption; if it is a
BOOL, it is not an f-type! f- is for Flags, meaning some bit pattern derived from |
logic. Or why is dwMask not fMask? Who CARES if it is DWORD declaration? The list goes
on and on...)

Microsoft adopted it and has a tendency to not let go of bad ideas, and did it to death.
Therefore, I consider its use in all Microsoft products as merely an example of how a
corporate tradition can propagate fundamentally bad ideas long past their useful lifetime,
and in any case since nearly ALL instances in Windows are a misuse of the original idea,
all uses in Windows are suspect.

I see no reason to continue to live with the mistakes imposed on us by obsolete and
irrelevant software. We are living in a world of C with prototypes and C++, and we should
live in that world, not the world of the mid-1970s or the mid-1980s. Otherwise, we should
all be programming in FORTRAN, PASCAL, and Algol-60. Our tools mature, and we should
mature with them, not carry obsolete methodologies around because they once had a purpose.
And we should certainly not carry around perversions of what may have been sound ideas at
the time.
joe

.