匈牙利約定優點
匈牙利約定與其它命名約定一樣，擁有由命名約定所帶來的一切共同優點。由于有這樣
多的標準名稱，因此在任何一個單個子程序或程序中要特殊記憶的名字是非常少的。匈牙利
約定完全可以在不同項目中采用。
匈牙利約定可以使得在命名中容易產生定義的區域變得準確清楚。特別是約定中對
First，Min，Last，Max 和 Lim 的準確區分在實際中是尤其有幫助的。匈牙利約定可以使
人對編譯程序無法檢查的抽象數據類型進行檢查：cpaReformat[i]很可能是錯誤的，因為
cpaReformat 不是數組，而 apaReformat[i]則可能是正確的，因為 apaReformat[i]是數
組。
匈牙利約定可以在類型不嚴格的語言或環境中對類型進行說明。例如，在 Windows 環
境下編程時，需要你放棄許多類型，這極大地限制了編譯程序進行嚴格類型檢查的能力。
而建立約定則可以對環境的這一弱點作出補償，匈牙利約定還可以使名稱更簡潔，可以用
CMedals 而不用 TotalMedals 來代表獎牌的數量，使用 pNewScore，而不是用
NewScorePtr 命名一個新分數指針。

匈牙利約定缺點
一些版本的匈牙利約定事實上忽視了用抽象數據類型作為基本類型。它們以程序語言
中整型、長整型、浮點數和字符串為基礎來建立基本類型。匈牙利約定基本類型事實上是
沒有什么價值的，因為它使得程序員陷入對類型進行人工檢查的困擾之中，而不是讓編譯
程序對類型進行更加快速而又準確的檢查。
這種形式匈牙利約定的另一個問題是它把數據的意義與其表現聯系在一起。比如，說
明某一變量是整型的，把它改為長整型的時，不得不改動這一變量的名稱。
匈牙利約定的最后一個問題是它鼓勵了懶惰、不含什么信息的變量名的出現。當程序
員用hwnd 來命名對窗口的操作時，往往忽視了他所指的到底是哪種窗口、對話框、菜單還
是幫助區的屏幕？顯然用 hwndmenu 要比 hwnd 清楚得多。以變量的意義為代價來獲得對
其類型的精確描述顯然是愚蠢的。不過好在可以用加限定詞的辦法來同時獲得完整的意義
和精確的類型。