作爲一個開始的程序員，我試圖爲自己解決一個標準的命名約定。我意識到這是個人偏好，但我試圖從你們中的一些人那裏得到一些想法（很多人），他們比我更聰明。你在C＃中使用什麼命名約定？
我不是在談論駱駝符號，而是你如何命名變量等。恕我直言，var_Quantity比Q或varQ更具描述性。但是，如何避免變量變得太長。我試圖對命名我的控件進行更具描述性的描述，但是我最終得到了一些像「rtxtboxAddrLine1」這樣的RadTextBox，其中包含地址欄1.同樣，這是無法管理的，儘管它很清楚控件是什麼。
我只是好奇，如果你有一些指導，你遵循或我留給自己的設備？
一些basic rules can be found here。和much more extended rules can be found here。這些是Microsoft框架設計人員的官方指導。
至於你的例子，應該簡單地調用該變量quantity。
描述性越好越好，你會發現長度不像記住那個控制/變量在路上行走五年那麼重要。
有幾個好的編碼標準文件可在網上大衛 - 蘭斯寫道之一： http://weblogs.asp.net/lhunt/attachment/591275.ashx
對於.NET API設計（和一些通用的C＃指南）檢查克齊斯茨托夫·克瓦林納和布拉德·艾布拉姆斯Framework Design Guidelines
問候， tamberg
我建議你使用微軟自己的準則作爲出發點。通常，大多數公司都是從那裏開始的（無論如何，以我的經驗）。
http://msdn.microsoft.com/en-us/library/czefa0ke(VS.71).aspx
在這種情況下，我想你會更好，將其命名爲primaryAddressLine或firstAddressLine。這是爲什麼 - rtxt作爲前綴無用地告訴你的類型。 Intellisense將幫助您使用該類型，並且不受對實際對象類型所做更改的影響。調用它firstAddressLine使它遠離在變量名稱末尾使用1,2,3（...）的（窮）慣例，以表明由於某種原因，您需要更多的而不是集合。
將其命名爲它所表示的內容/如何解釋或使用它的數據類型，以及如果不需要，則在命名時不縮寫。
我通常會嘗試遵循微軟的指導方針，拋出一些非常古老的習慣。
所以，我仍然不能擺脫用下劃線_privateMember前綴私人的習慣。
我已經老了，那已經燒進了我的大腦。
就前綴控制小部件而言，我發現如果您的描述太具描述性，那麼在將UI改爲沿着軌道的情況下，會變得很痛苦。
例如你有一個名爲ddlProductLine的下拉列表，然後它必須改變爲一個單選按鈕組，你的前綴約定開始比PITA更有幫助。
當你有很多小部件的工作，有時像uiCtl更一般前綴可以與雜亂的幫助，但還是明智的，如果你要改變小工具類型。
的Guidelines for Names是最好的起點。但是，正如在其他生活領域一樣，一旦你瞭解了規則，你就會開始知道打破它們的合理位置。
我從來沒有使用舊的匈牙利表示法，這種表示法叫做strFirstName，intCount等;但我還是用它控制：txtFirstName，btnVerifyData等原因包括：
此外，我很可能會對頁面或窗體上的許多TextBoxes或ComboBoxes執行相同的操作，而我不太可能對所有引用的整數或字符串一個頁面或表單。所以它能夠幫助我們快速找到所有文本框以及它們的前綴txt。
還有其他的，但是，即使在這種情況下，堅決反對匈牙利，我敢肯定，他們有他們的理由。無論您的個人風格如何，您都可能會發現自己的團隊風格非常不同。在這種情況下，只要做他們的工作;這是非常非常非常值得解決的問題。我唯一這樣做的時候是，如果他們的風格導致了很多錯誤，但是離開我的頭頂，我想不出會造成這種情況的情況。
感謝您的支持。我打印出來了！ – GregD 2008-11-20 22:28:31