除了在用戶界面中，我已經停止使用匈牙利表示法，其中經常有用戶名標籤，用戶名文本框，用戶名局部變量，必需的字段驗證器，用戶名屬性和方法參數等，通常都在相同的情況下。在UI中替換/避免匈牙利符號的命名建議？
電流：lblUser，txtUser，rfvUser，_user，用戶，用戶
如果我做明顯的，編號userLabel，UserTextBox，UserRequiredFieldValidator，好像我只是substiuting長後綴短的前綴。
而_表示字段，被FxCop標記，但沒有前綴，它會與批准的用戶/用戶約定衝突。
有什麼建議嗎？
我仍然一般使用匈牙利符號的UI對象，因爲我發現它使我的代碼更具可讀性。
我會使用m_firstNameTextBox或m_countryComboBox作爲UI控件，然後使用m_firstName和m_country作爲來自這些控件的字符串值。
在一天結束時，你應該使用任何你喜歡的。避免使用匈牙利符號的一攬子規則與規定對其進行宗教使用的規則一樣糟糕。 intCounter，strName之類的東西都是過時的，但在其他情況下，它指出變量名稱中類的類型是合理的，在我看來，UI控件恰好是其中的一種情況。
我更喜歡匈牙利語，即使它會導致用戶界面中的真正長名稱（因爲您提到的問題）。我唯一的建議是在整個團隊中保持一致。
匈牙利符號沒有什麼不妥，只要它用於使代碼更具可讀性即可。如果你認爲它不起作用，那就不要使用它。
啊，請不要同時使用'用戶'和'用戶'。 閱讀，使用，維護和移植很困難。如果兩種不同的東西具有兩種不同的含義，那麼匈牙利符號比通過在大寫字母/小寫字母之間翻轉字符來編碼該信息更好。
我不知道是誰在程序語言中發明了區分大小寫的東西，但是他的確造成了比當時任何人都想象的更多的傷害。我討厭收到編譯器錯誤，因爲我輸入「ID」而不是「標識」或「軟膠U盤」時，它應該已經「軟膠U盤」。
使用全部小寫和下劃線，並且案例問題消失。 SomeIdiotSomewhereDecidedThisWasAGoodWayToDoThingsAndIfIFindHimIWillKillHim。
我認爲區分大小寫並不像默認的那樣簡單，因爲它在計算上比較便宜（至少在ASCII系統上）。我的印象是，更新的和更高級的語言更可能對標識符不區分大小寫。 – cheduardo 2009-06-15 11:50:00
是的，如果字符完全相等，則比較容易。甚至不要讓我開始關於unicode源代碼。這是一個婊子閱讀，我甚至不知道如何輸入大部分字符。 – 2009-06-16 00:10:49