int，string，array，list，object等可接受的命名約定是什么

Question

我現在工作的公司為它們的C＃變量使用一組命名約定，例如iSomeName用於int，sSomeName用於字符串，aSomeName用於數組，bSomeName用於布爾值，dSomeName用於datetime等等。 我以前的雇主沒有使用i，s，a，b和d前綴，只是將變量命名為一個很好理解的名稱。 我的印象是，這些前綴在不久前失寵了，從我讀到的不是當前的趨勢。 對我來說似乎很好，只要變量具有足夠的描述性來理解它正在做什么，但我想知道現在一天接受的做法是命名變量？

Answer 1

好吧，很多命名取決於你使用的語言.. camelCase或PascalCase或underscore_variables 。 正確命名/可讀/可理解是最重要的事情。

關於這個前綴 （或匈牙利表示法）：它在MSDN中具體說明：C＃文章中的一般命名約定 ：

[...]

不要使用匈牙利表示法。

匈牙利表示法是在標識符中包括前綴以編碼關於參數的一些元數據的實踐，例如標識符的數據類型。

[...]

Answer 2

對這些問題的通常建議是在您自己的代碼內和雇主內部保持一致; 如果您的雇主使用匈牙利表示法，您也應該使用它，無論接受的做法如何。

Answer 3

您以前的雇主更符合當前的做法。 使用代碼對變量進行前綴不是最佳實踐 。 你應該現在只做它，如果它澄清代碼，它通常不會。 對任何類型的前綴的明顯需求應被視為次要的Code氣味 ，表明當前的例程可能過於復雜。 花時間改善代碼而不是添加前綴。

有關此練習的歷史，請參閱匈牙利表示法 。 名為Apps Hungarian表示法的版本意味着前綴有助於指示變量的用途，而不是其類型。 每隔一段時間這是合法的，但很少有必要。 更常見的做法稱為系統匈牙利表示法 ，其中前綴表示類型。 （幸運的是）這種情況變得不那么常見了。

不要太沮喪，不得不這樣做。 我們不得不實施許多更糟糕的做法。 如果這很糟糕，你很幸運。 有一些標准 （只要他們不瘋狂）比沒有標准更好。

Answer 4

“現代”和“流行”的方式是沒有匈牙利表示法（i，s等）。 原因是重構不再是一個問題。 這意味着本質上是批量更改代碼而不是特定時間。 當你重構東西時，匈牙利表示法很難做到正確，因為它往往是在各種工具的幫助下完成的，而這些工具並不知道每個人的自定義匈牙利表示法標准。

想象一下，如果你在一個整數的對象上有一個iAge成員變量。 那么，如果你想將這個從int更改為long因為這個年齡是以毫秒為單位的呢？ 那么，你現在還必須將它重命名為lAge 。 更改類型很容易，也可以自動化，但“創意標准命名”要難得多。 實際上，在這個Age變量之前有一個i或者l，它真的告訴你關於代碼在做什么的更多信息嗎？ 當然，它告訴您數據類型，但在任​​何現代IDE中將鼠標懸停在它上面，它也會告訴您數據類型。

簡而言之，“現代偏好”確保您的代碼的意圖易於准備。 像匈牙利表示法中的數據類型這樣的微不足道的東西只會讓人感到困惑。 代碼很難閱讀 - 不要讓它變得更糟！

Answer 5

C＃現代公認的做法是不使用匈牙利表示法。 相反，最佳做法是使用可理解的描述性變量名稱。

StyleCop通常用於在C＃中強制執行代碼格式化標准，並且默認情況下不允許匈牙利語表示，盡管它允許通過配置進行異常。

Answer 6

您當前的雇主使用的是匈牙利語系統表示法

我個人認為這個命名約定沒有價值，因為大多數開發環境都會提供彩色語法高亮和變量檢查，因此您可以輕松確定類型。 在最壞的情況下，它會讓人感到困惑，因為您可能會更改變量的類型但不會更改變量“prefix”：

double iCount = 0.0;

Answer 7

你需要參考框架設計指南 ，特別是第3章相同的信息（不帶注釋的“背后的故事”）可在網上 。

您當前雇主使用的命名系統稱為匈牙利表示法，不再由Microsoft推薦。 （事實上​​，大多數地方不再使用它了。）

Answer 8

是的，匈牙利語不再使用了，我認為最好使用有意義的有意義的名字。

如果你想閱讀一篇很好的文章（也許轉發給大假發：P）關於它，請查看Joel對制作代碼丑陋和匈牙利符號的看法 ，這是為什么匈牙利符號的制作，以及如何它已經被幾代人濫用了。