書上說匈牙利命名法已經過時了，我不這樣認為。
有人認為現在編譯器已經可以很好的檢測出類型的不匹配，或者IDE中可以很快的看到類型，所以在c中可能需要，在C＋＋（強類型語言）中就不需要了。
C++ made it harder to do that without wicked casting and the compiler catches most of those kind of errors.? So, I agree with the previous poster that it's now redundant.
Also, modern IDEs allow you to hover the cursor over a variable and show you the variable's definition.
不過我覺得代碼不是寫給編譯器看的，而是寫給人看的，這里就有self-documenting和readability的問題。
很明顯，如果你看到nIndex 或者strFile或者wndNext，就可以很快知道分別是int CString CWnd類型，而不用回頭去看變量定義，這樣，看代碼時就會很快。
而且，對于MFC程序員來說，更重要一些，因為MFC里面的變量都是用匈牙利命名法的。
If you're programming C++/MFC you're better sticking to hungarian for consistency with the class library & Win32 API declarations.
微軟的約定，就是標準了 
不過，書上提到在泛型編程中不需要，現在體會還不深，可能是對的。
今天(2006 04 13碰巧看到codeproject的一個vote),結果如下
|
Option
|
Votes
|
%
|
| Pascal Cased |
171 |
10.6
|
| camel Cased |
702 |
43.4
|
| Fixed letter prefix (eg lLocal) |
81 |
5.0
|
| Hungarian prefix (eg strLocal) |
481 |
29.7
|
| Scope prefix (eg l_Local) |
36 |
2.2
|
| Scope and Hungarian prefix (eg l_strLocal) |
125 |
7.7
|
|
Responses
|
1618
|
? |
Hungarian Notation排第二.
cp上面有兩個鏈接
Conversations: Hungarian wartHogs (
http://www.cuj.com/documents/s=7989/cujcexp1911hyslop/hyslop.htm)
號稱這篇文章就已經明白的說HN過時了(作者也是
c++ coding stardard的作者).
如果不用HN,那么應該用什么樣的命名規則呢?
Naming Guidelines(
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconNamingGuidelines.asp)
.Net下的推薦,也許別的地方也可以用.