C＃中的類型/命名空間別名約定

在C＃中定義namespace or type aliases是否有任何已建立的命名或編碼約定？C＃中的類型/命名空間別名約定

對於那些不知道的人，C＃語言有一個特性，可以在名稱空間和類型的文件中定義別名。當與第三方庫命名衝突以及縮短代碼中的類型名稱時，這會很有用。下面是它看起來像的一個例子。

using Forms = System.Windows.Forms;

大多數的，我已經在網絡上看到的例子傾向於使用未縮寫的大寫名稱作爲別名，如別名形式在上面的例子。在某些地方，包括official MSDN page，其中解釋了示例，其別名爲colAlias命名空間System.Collections。爲了使它更復雜，可能會有一些人根據是否定義了名稱空間別名或類型別名來選擇不同的準則。

爲了給我一些背景知道爲什麼我感興趣的任何指南與別名我會解釋我在做什麼。在最近的一個項目中，我開始簡化一個模式，其中有幾個類繼承自通用基類，它通過使用類型別名接受複雜類型參數。

因此，使用這種技術，下面的複雜例子變得更可讀，一旦類型別名被應用。

public class MyClass: MyGenericBaseClass<TripleLindyFancyAlgorithm<List<SomeValueType>>, List<SomeValueType>> 
{ 
    public override List<SomeValueType> DoSomething(TripleLindyFancyAlgorithm<List<SomeValueType>> operation) 
    { 
     // ... 
    } 
}

而且在使用類型別名的must cleaner版本下面。

using Result = List<SomeValueType>; 
using Algorithm = TripleLindyFancyAlgorithm<List<SomeValueType>>; // Note: cannot reference an alias within an alias definition! 

public class MyClass: MyGenericBaseClass<Algorithm, Result> 
{ 
    public override Result DoSomething(Algorithm operation) 
    { 
     // ... 
    } 
}

雖然這看起來更簡單，人們很容易忘記，一個別名，如結果實際上只是一個別名列表，並沒有所謂的結果實際類型。爲了從視覺上分離這些概念，我正在考慮遵循一些類似於在私有成員之前使用下劃線'_'的前綴約定，以幫助將類型別名與實際類型區分開來。在我這樣做之前，我想確保我沒有重新發明輪子，因爲可能已經有更多已經建立的公約。

來源

2009-10-29 jpierson

命名空間別名不是大多數代碼庫的共同特徵 - 當我使用它時，最後一個地方是高級開發人員不熟悉它，儘管已經與C＃合作多年。

由於它很少見，因此尚未制定其慣例。

我會說，如果您打算使用別名，請與您的團隊討論以創建您自己的約定。

幾種不同的方法，我已經看到了使用別名：

命名空間的縮寫。通常是命名空間中的首字母。
命名空間的最後 - 如果複數去除複數。
描述性短名稱。

來源

2011-12-09 19:15:06 Oded

偉大的這是真正的討論公約的第一篇文章，這是我最初提出的通過提出這個問題所做的。 – jpierson 2011-12-12 17:52:09

獲得賞金。感謝您解決被問到的問題（即不僅僅是陳述您自己的偏好），並以真實世界的經驗爲其提供支持。 – 2011-12-15 10:15:37

@MthethewStrawbridge - 謝謝你。正如你所說，其他答案似乎並沒有解決這個問題，而是說明了個人喜好。答案中的不一致還表明，關於命名空間別名的約定確實沒有達成共識... – Oded 2011-12-15 10:17:56

就我個人而言，我只會用它來保持智能感。

using StringBuilder = System.Text.StringBuilder;

如果您重命名類型，則爲維護程序員打開潘多拉盒子。

來源

2009-10-29 20:14:32 ChaosPandion

雖然我同意在不保證的情況下使用這種技術會對維護非常不利，但我認爲沒有任何改進的原始複雜示例可能更加值得關注。 – jpierson 2009-10-29 20:21:31

我可能會很瘋狂，但我認爲它是如此明確時更具可讀性。 – ChaosPandion 2009-10-29 20:34:35

ChaosPandion，也許你的權利。然而，要點討論命名約定，但我認爲重要的是考慮關於使用別名的編碼準則。 – jpierson 2009-10-30 23:57:01

我只會在命名空間衝突的情況下使用別名（即僅當我的有時）。

至少對我來說，任何其他用途只是令人困惑和分心。

來源

2009-10-29 20:14:35

但是你必須承認，在我給出的例子中，如果你必須編寫100 +以上類似的類，它們都具有相同的模式，以便類型別名功能顯着提高可讀性。儘管我同意這可能會令人困惑，但我認爲在這種類型的例子中，即使不是更復雜的事情，也不例外。 – jpierson 2009-10-29 20:18:47

關於這個例子 - 嵌套泛型，深層幾乎從來沒有必要，如果是，這是一個跡象表明類應該重新設計，而不是一個符號應該使用別名。這對凡人來說太過撲朔迷離。 – 2011-12-13 16:30:39

@Dave - 一個非常有效的觀點，儘管要深入到設計細節中，但我不得不透露實際代碼的細節，這些細節促使我問這個問題。爲了提高工作效率，我會盡量少關注於示例的合理性以及是否應該使用類型別名，以及更多關於C＃代碼中的類型別名的約定。 – jpierson 2011-12-14 14:13:01

命名空間的別名兩種最常見的情況是：

我看見了，我用它（作爲一種趨勢）
我端口代碼從另一種語言

對於第一種情況，沒有評論。對於第二個一個很好的例子是從C和使用命名空間別名移植代碼的實用性，如：

using i64 = System.Int64; 
using u8 = System.Byte; 
using u32 = System.UInt32; 
using u64 = System.UInt64;

即使你認爲上面的別名懶編程，它們有助於避免錯誤。

來源

2011-12-11 19:49:41

您的代碼示例不是名稱空間別名，而是類型別名（均使用'using'指令完成）。 – Oded 2011-12-12 18:11:58

沒錯。就像「使用StringBuilder = System.Text.StringBuilder;」來自ChaosPandion。迄今爲止我的經驗表明，大多數人都把它當作命名空間別名來思考。 – 2011-12-12 18:16:35

大多數人可能會使用它們互換，如果他們使用它們。 – Oded 2011-12-12 18:17:40

我認爲傾向於根本不使用它們的人是給出您要求的答案。那是的慣例。這並不是說它不會有用，但不使用它仍然是常態。

來源

2011-12-15 00:37:47

公平評估，請考慮對某人的回答或我原來的問題發表評論。 – jpierson 2011-12-15 20:17:20

爲什麼在一些人反對使用using的時候，沒有人說這是對「在C＃中定義名稱空間或類型別名是否有任何確定的命名或編碼慣例？」這個問題的答案？我的確如此:) – 2011-12-16 10:59:57

所以我想你的答案是「不」，如果是這樣，那將是一個簡單而可接受的答案。雖然很明顯，其他人認爲雖然可能不是很普遍或一致，但有一些公約。 – jpierson 2011-12-17 06:40:34

您可以採用約定將其用於抽象。

using Id = System.Int32;

這樣你就可以很容易地只更換

using Id = System.Guid;

該線在某些時候並沒有其他的代碼將不得不改變（假設你沒有通過抽象建立在依賴偷看實際的類型......）

來源

2012-05-05 22:15:27

這適用於簡單的類型，但是一旦您擁有類或泛型，就會有一些痛苦，因爲這些方法很少共享，除非像ToString（）這樣非常普遍的情況。無論如何，我傾向於這樣做，因爲你列出的原因。它實際上提高了可讀性以指定在使用它的上下文中有意義的類型。 – 2013-11-12 23:26:53

我一般只使用它們時，我需要在不同的命名空間使用兩個類似的命名類，不希望完全指定的代碼類型：

using xItem = My.Project.NameSpace.Item; 
using yItem = Your.ThirdParty.Framework.Item;

來源

2013-04-11 14:30:27

C＃中的類型/命名空間別名約定

回答

相關問題