Prev: Combine list view with a tab ctrl
Next: CWnd derived parent, owner draw reflection does not work
From: Tom Serface on 22 Feb 2010 13:11
Of course if the code writers had wrapped this in classes with setters and
getters there wouldn't be this problem since the names of the revealed
variables could be more innocuous.

I find using some sort of indication of the variable type in the name makes
it easier for me when I read my own code. For example, I often use:

m_cs - CString
m_b - boolean
m_n - numeric type
m_p - pointer
m_c - control
etc.

Not "Hungarian", but still somewhat descriptive. I would never want to type
lpstr... just too lazy.

Tom

"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
news:1g15o5t5hhdom0to5rm9idt80p3nfdg4vv(a)4ax.com...
> On of the reasons for doing careful design on day one is that you are
> stuck with bad
> decisions forever. Witness the horrid number of bad examples of Hungarian
> Notation
> failing completely because the data types HAD to change and they stupidly
> included the
> datatype in the name (LPVOID lpstrAlgorithm is one of the more memorable
> ones, but the
> number of UINT wWhatevers is pretty high, too. Just think: if HN hadn't
> been used, there
> would be no discontinuity!)
> joe
>
> On Mon, 22 Feb 2010 09:43:35 +0100, Hans-J. Ude
> <news(a)s237965939.online.de> wrote:
>
>>Joseph M. Newcomer wrote:
>>
>>>Actually, the speculation is much simpler:
>>>
>>><speculation>
>>>The people who programmed Windows 1.0 in 1984 had NO IDEA about signed
>>>vs. unsigned.
>>>Totally clueless.
>>></speculation>
>>
>>That's what I thought too, it's legacy. If they change it in the next
>>SDK then probably thousands of programs wouldn't compile anymore. Or,
>>if they compile, possibly end up in malfunction, depending on how they
>>are written.
>>
>>Hans
> Joseph M. Newcomer [MVP]
> email: newcomer(a)flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm

From: Giovanni Dicanio on 23 Feb 2010 04:52
"Tom Serface" <tom(a)camaswood.com> ha scritto nel messaggio
news:e6Wytp#sKHA.4752(a)TK2MSFTNGP04.phx.gbl...

> I find using some sort of indication of the variable type in the name
> makes it easier for me when I read my own code. For example, I often use:
>
> m_cs - CString
> m_b - boolean
> m_n - numeric type
> m_p - pointer
> m_c - control
> etc.
>
> Not "Hungarian", but still somewhat descriptive. I would never want to
> type lpstr... just too lazy.

One problem of the prefixes is that they could be ambiguous...
For example, I used to choose "b" prefix for BYTEs (like the Win32 SDK
does).

However, I think that sometimes Hungarian Notation is misinterpreted.
My understanding of the *real* HN is that its intent is to help the
programmer catching errors that the compiler can't catch.
I'll give you a sample here:

Consider a Unicode NUL-terminated string (i.e. WCHAR * or LPWSTR) and a
BSTR.
From the C/C++ type system point of view, a BSTR is just a LPWSTR!
So, the following C++ code would compile just fine:

WCHAR * s1 = L"Foo";
BSTR s2;
...
...
s2 = s1;

But the above code is *wrong*. In fact, for example, a BSTR is length
prefixed (and this condition is not met by above code); moreover, the BSTR's
should be allocated using SysAllocString, etc.
So, you have a C++ code that compiles but has a hidden bug in the 's2 = s1'
statement.

Instead, if you use proper notation, you can identify the bug reading code:

WCHAR * pszS1 = L"Foo";
BSTR bstrS2;
...
..
bstrS2 = pszS1;

--> wrong assignment (prefixes don't match: can't assign a BSTR from a
LPWSTR).

Another similar case is the 'cch' vs. 'cb'. Both can be integer types, but
you know that one is the count of characters, the other is the count of
bytes.

I have mixed feelings about HN, but a properly used notation about the
*semantics* of the variable (not about the raw underlying C++ type) may
help.

Giovanni


From: Tom Serface on 23 Feb 2010 09:47
Yeah, I guess there is no perfect method. I'm not sure how to solve that
debate. I guess we all have to use what means the most to us and just do a
lot of commenting. I've found that right clicking and selecting Go to
declaration is a great help ...

Tom

"Giovanni Dicanio" <giovanniDOTdicanio(a)REMOVEMEgmail.com> wrote in message
news:ukvHe3GtKHA.3360(a)TK2MSFTNGP06.phx.gbl...
> "Tom Serface" <tom(a)camaswood.com> ha scritto nel messaggio
> news:e6Wytp#sKHA.4752(a)TK2MSFTNGP04.phx.gbl...
>
>> I find using some sort of indication of the variable type in the name
>> makes it easier for me when I read my own code. For example, I often
>> use:
>>
>> m_cs - CString
>> m_b - boolean
>> m_n - numeric type
>> m_p - pointer
>> m_c - control
>> etc.
>>
>> Not "Hungarian", but still somewhat descriptive. I would never want to
>> type lpstr... just too lazy.
>
> One problem of the prefixes is that they could be ambiguous...
> For example, I used to choose "b" prefix for BYTEs (like the Win32 SDK
> does).
>
> However, I think that sometimes Hungarian Notation is misinterpreted.
> My understanding of the *real* HN is that its intent is to help the
> programmer catching errors that the compiler can't catch.
> I'll give you a sample here:
>
> Consider a Unicode NUL-terminated string (i.e. WCHAR * or LPWSTR) and a
> BSTR.
> From the C/C++ type system point of view, a BSTR is just a LPWSTR!
> So, the following C++ code would compile just fine:
>
> WCHAR * s1 = L"Foo";
> BSTR s2;
> ...
> ...
> s2 = s1;
>
> But the above code is *wrong*. In fact, for example, a BSTR is length
> prefixed (and this condition is not met by above code); moreover, the
> BSTR's should be allocated using SysAllocString, etc.
> So, you have a C++ code that compiles but has a hidden bug in the 's2 =
> s1' statement.
>
> Instead, if you use proper notation, you can identify the bug reading
> code:
>
> WCHAR * pszS1 = L"Foo";
> BSTR bstrS2;
> ...
> ..
> bstrS2 = pszS1;
>
> --> wrong assignment (prefixes don't match: can't assign a BSTR from a
> LPWSTR).
>
> Another similar case is the 'cch' vs. 'cb'. Both can be integer types, but
> you know that one is the count of characters, the other is the count of
> bytes.
>
> I have mixed feelings about HN, but a properly used notation about the
> *semantics* of the variable (not about the raw underlying C++ type) may
> help.
>
> Giovanni
>
>
From: BobF on 23 Feb 2010 10:53

I find the little tooltips that pop up showing how vars are defined
helps a bunch too!



Tom Serface wrote:
> Yeah, I guess there is no perfect method. I'm not sure how to solve
> that debate. I guess we all have to use what means the most to us and
> just do a lot of commenting. I've found that right clicking and
> selecting Go to declaration is a great help ...
>
> Tom
>
> "Giovanni Dicanio" <giovanniDOTdicanio(a)REMOVEMEgmail.com> wrote in
> message news:ukvHe3GtKHA.3360(a)TK2MSFTNGP06.phx.gbl...
>> "Tom Serface" <tom(a)camaswood.com> ha scritto nel messaggio
>> news:e6Wytp#sKHA.4752(a)TK2MSFTNGP04.phx.gbl...
>>
>>> I find using some sort of indication of the variable type in the
>>> name makes it easier for me when I read my own code. For example, I
>>> often use:
>>>
>>> m_cs - CString
>>> m_b - boolean
>>> m_n - numeric type
>>> m_p - pointer
>>> m_c - control
>>> etc.
>>>
>>> Not "Hungarian", but still somewhat descriptive. I would never want
>>> to type lpstr... just too lazy.
>>
>> One problem of the prefixes is that they could be ambiguous...
>> For example, I used to choose "b" prefix for BYTEs (like the Win32 SDK
>> does).
>>
>> However, I think that sometimes Hungarian Notation is misinterpreted.
>> My understanding of the *real* HN is that its intent is to help the
>> programmer catching errors that the compiler can't catch.
>> I'll give you a sample here:
>>
>> Consider a Unicode NUL-terminated string (i.e. WCHAR * or LPWSTR) and
>> a BSTR.
>> From the C/C++ type system point of view, a BSTR is just a LPWSTR!
>> So, the following C++ code would compile just fine:
>>
>> WCHAR * s1 = L"Foo";
>> BSTR s2;
>> ...
>> ...
>> s2 = s1;
>>
>> But the above code is *wrong*. In fact, for example, a BSTR is length
>> prefixed (and this condition is not met by above code); moreover, the
>> BSTR's should be allocated using SysAllocString, etc.
>> So, you have a C++ code that compiles but has a hidden bug in the 's2
>> = s1' statement.
>>
>> Instead, if you use proper notation, you can identify the bug reading
>> code:
>>
>> WCHAR * pszS1 = L"Foo";
>> BSTR bstrS2;
>> ...
>> ..
>> bstrS2 = pszS1;
>>
>> --> wrong assignment (prefixes don't match: can't assign a BSTR from a
>> LPWSTR).
>>
>> Another similar case is the 'cch' vs. 'cb'. Both can be integer types,
>> but you know that one is the count of characters, the other is the
>> count of bytes.
>>
>> I have mixed feelings about HN, but a properly used notation about the
>> *semantics* of the variable (not about the raw underlying C++ type)
>> may help.
>>
>> Giovanni
>>
>>
From: Joseph M. Newcomer on 23 Feb 2010 13:31
One of the reasons HN no longer has any value whatsoever!
joe

On Tue, 23 Feb 2010 09:53:42 -0600, BobF <nothanks(a)no.spam> wrote:

>
>I find the little tooltips that pop up showing how vars are defined
>helps a bunch too!
>
>
>
>Tom Serface wrote:
>> Yeah, I guess there is no perfect method. I'm not sure how to solve
>> that debate. I guess we all have to use what means the most to us and
>> just do a lot of commenting. I've found that right clicking and
>> selecting Go to declaration is a great help ...
>>
>> Tom
>>
>> "Giovanni Dicanio" <giovanniDOTdicanio(a)REMOVEMEgmail.com> wrote in
>> message news:ukvHe3GtKHA.3360(a)TK2MSFTNGP06.phx.gbl...
>>> "Tom Serface" <tom(a)camaswood.com> ha scritto nel messaggio
>>> news:e6Wytp#sKHA.4752(a)TK2MSFTNGP04.phx.gbl...
>>>
>>>> I find using some sort of indication of the variable type in the
>>>> name makes it easier for me when I read my own code. For example, I
>>>> often use:
>>>>
>>>> m_cs - CString
>>>> m_b - boolean
>>>> m_n - numeric type
>>>> m_p - pointer
>>>> m_c - control
>>>> etc.
>>>>
>>>> Not "Hungarian", but still somewhat descriptive. I would never want
>>>> to type lpstr... just too lazy.
>>>
>>> One problem of the prefixes is that they could be ambiguous...
>>> For example, I used to choose "b" prefix for BYTEs (like the Win32 SDK
>>> does).
>>>
>>> However, I think that sometimes Hungarian Notation is misinterpreted.
>>> My understanding of the *real* HN is that its intent is to help the
>>> programmer catching errors that the compiler can't catch.
>>> I'll give you a sample here:
>>>
>>> Consider a Unicode NUL-terminated string (i.e. WCHAR * or LPWSTR) and
>>> a BSTR.
>>> From the C/C++ type system point of view, a BSTR is just a LPWSTR!
>>> So, the following C++ code would compile just fine:
>>>
>>> WCHAR * s1 = L"Foo";
>>> BSTR s2;
>>> ...
>>> ...
>>> s2 = s1;
>>>
>>> But the above code is *wrong*. In fact, for example, a BSTR is length
>>> prefixed (and this condition is not met by above code); moreover, the
>>> BSTR's should be allocated using SysAllocString, etc.
>>> So, you have a C++ code that compiles but has a hidden bug in the 's2
>>> = s1' statement.
>>>
>>> Instead, if you use proper notation, you can identify the bug reading
>>> code:
>>>
>>> WCHAR * pszS1 = L"Foo";
>>> BSTR bstrS2;
>>> ...
>>> ..
>>> bstrS2 = pszS1;
>>>
>>> --> wrong assignment (prefixes don't match: can't assign a BSTR from a
>>> LPWSTR).
>>>
>>> Another similar case is the 'cch' vs. 'cb'. Both can be integer types,
>>> but you know that one is the count of characters, the other is the
>>> count of bytes.
>>>
>>> I have mixed feelings about HN, but a properly used notation about the
>>> *semantics* of the variable (not about the raw underlying C++ type)
>>> may help.
>>>
>>> Giovanni
>>>
>>>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Combine list view with a tab ctrl
Next: CWnd derived parent, owner draw reflection does not work