C# 字段命名指南？

Question

我將自己編寫一些 C# 代碼，但我想確保我遵循最廣泛接受的命名約定，以防我想招募其他開發人員、發布我的代碼或出售我的代碼。 現在我正在遵循 Microsoft 設定的命名約定，因為它們似乎是最被廣泛接受的。 他們沒有提到的一件事是為私有字段命名。 在大多數情況下，我看到它們以駝峰命名，就像受保護的字段一樣，但是這給我帶來了一個問題，因為參數名稱應該以駝峰命名。 以下面的構造函數為例：

public GameItem(string baseName, string prefixName, string suffixName)
{
    //initialize code
}

現在，如果我對私有字段也使用駝峰命名法，則會出現命名沖突，除非我使用“this”來訪問類字段（我認為這違反了大多數標准，更不用說意味着更多的輸入）。 一種解決方案是為參數指定不同的名稱，但為相同的數據指定 2 個不同的名稱是不合邏輯的。 我所知道的在 C++ 編碼中常見的唯一其他解決方案是在開始時給私有成員一個下划線 (_camelCase)。 C# 編碼普遍接受該解決方案嗎？ 這個問題是否有另一種解決方案（例如僅使用屬性（使用 PascalCase）來訪問字段，即使在類本身中也是如此）？

Answer 1

_camelCase字段在我看到的情況下很常見（這是我們在我們的地方使用的，Microsoft 更喜歡 .NET Runtime ）。

我個人使用這個標准的理由是輸入_來識別私有字段比this.更容易this.

例如：

void Foo(String a, String b)
{
    _a = a;
    _b = b;
}

相對

void Foo(String a, String b)
{
    this.a = a;
    this.b = b;
}

我發現第一個更容易輸入，它可以防止我意外分配給名為a而不是this.a的參數。 代碼分析可維護性規則加強了這一點，該規則指出：

• CA1500變量名稱不應與字段名稱匹配。

我的另一個原因，就是this. 是可選的（Visual Studio / Code 提示您刪除它們），如果它不與局部變量或參數名稱沖突，則更難知道您使用的是哪個變量。 如果您在所有私有字段的開頭都有一個_ ，那么您總是知道哪個是一個字段，哪個是本地范圍。

Answer 2

遵循Microsoft 命名指南。 字段使用指南表明它應該是駝峰式大小寫而不是前綴。 注意一般規則是沒有前綴； 具體規則是不要前綴來區分靜態和非靜態字段。

不要對字段名稱或靜態字段名稱應用前綴。 具體來說，不要在字段名稱上使用前綴來區分靜態和非靜態字段。 例如，應用 g_ 或 s_ 前綴是不正確的。

和（來自通用命名約定）

不要使用下划線、連字符或任何其他非字母數字字符。

編輯：我會注意到文檔並不是針對私有字段的，而是指出受保護的字段應該只使用駝峰式命名。 我想你可以從中推斷出任何私有字段的約定都是可以接受的。 當然，公共靜態字段不同於受保護的（它們是大寫的）。 我個人的觀點是，protected/private 在范圍上的差異不足以保證命名約定的差異，尤其是當您似乎只想將它們與參數區分開來時。 也就是說，如果您遵循受保護字段的准則，則必須在這方面將它們與私有字段區別對待，以便將它們與參數區分開來。 我在指類中的類成員時使用 this來明確區分。

編輯 2

我采用了當前工作中使用的約定，即用下划線作為私有實例變量的前綴，並且通常僅將受保護的實例變量公開為使用 PascalCase（通常是自動屬性）的屬性。 這不是我個人的偏好，但我已經習慣了，並且可能會遵循它，直到出現更好的東西。

Answer 3

通常有兩種廣泛使用的方法來命名字段（總是使用camelCase ）：

使用下划線前綴

void F(String someValue) {
  _someValue = someValue;
}

使用this. 訪問該字段並避免名稱沖突

void F(String someValue) {
  this.someValue = someValue;
}

我個人更喜歡后者，但我會使用我工作的組織規定的任何約定。

Answer 4

簡短回答：使用_privateField ，即對私有字段使用前導下划線。

長答案：這里是...

很久以前，Microsoft 曾經建議對字段使用camelCase 。 見這里。 請注意該文檔的創建時間，2008 年 10 月 22 日。 很古老。

然而，微軟最近的代碼庫描繪了一幅不同的畫面。

1. 查看 .NET 運行時 GitHub 存儲庫的C# 編碼風格。 #3 是正在討論的點。 這是相關的部分

   我們將_camelCase用於內部和私有字段，並在可能的情況下使用readonly 。

2. 還要看一下Roslyn 存儲庫的編碼風格，它特別指出它遵循 .NET 運行時的約定。
3. 再看看.NET Standard 貢獻頁面，該 頁面還表示（至少現在）遵循與.NET CoreFX相同的指南，這是 .NET Runtime 的前身。
4. 在整合之前， CoreCLR還建議遵循與 CoreFX 相同的指南。
5. 甚至WinForms 存儲庫也談到使用相同的標准。
6. 我想我已經說得夠多了。 因此，總而言之，如果您想遵循 Microsoft 建議的指南，我想您知道該怎么做； 像這樣的私有字段使用前導下划線： _privateField 。

我的意見：我個人也更喜歡在我的私人領域使用前導下划線 - 使它很容易區分，而不需要this 。

Answer 5

在我們的商店中，我們使用 Microsoft 針對私人成員的建議指南開始了我們的第一個 C# 項目，即

camelCaseFieldName

但是我們很快就遇到了私有成員和參數之間的混淆，並切換到

_camelCaseFieldName

這對我們來說效果更好。

私有成員通常具有在方法調用之外持續存在的狀態 - 前導下划線往往會提醒您這一點。

另請注意，對屬性使用 AutoVariable 語法可以最大限度地減少對私有支持字段的需求，即

public int PascalCaseFieldName { get; set;}

有關（大部分）遵循 MS 指南的一套簡潔的標准，請查看net-naming-conventions-and-programming-standards---best-practices

Answer 6

正如前面提到的， 微軟命名指南不包括私有字段和局部變量命名。 而且您在 Microsoft 內部找不到一致性。 如果您在 Visual Studio 中生成類或一次性模式，它將創建類似

public MyClass(int value)
{
    this.value = value;
}

或者

private bool disposedValue = false; // To detect redundant calls

protected virtual void Dispose(bool disposing)
{
    if (!disposedValue)
    {
        ...
    }
}

幸運的是，越來越多的代碼被微軟開放了，所以讓我們來看看他們的 repos，例如ASP.NET Core MVC

private readonly IControllerActivator _controllerActivator;
private readonly IControllerPropertyActivator[] _propertyActivators;

或.NET 核心

private T[] _array;

您可能會說，它實際上不是 Microsoft，而是 .NET Foundation。 很公平，讓我們來看看微軟的 repos ：

private readonly MetricSeries zeroDimSeries;

但這里是古老的微軟 MVC 實現

private IActionInvoker _actionInvoker;

因此，沒有任何關於私有字段命名的常見做法或官方指南。 只需選擇您喜歡的一種並堅持下去。

Answer 7

飛利浦 Healtcare C# 編碼標准

MSDN - 埃里克·岡納森

編輯：我使用“this”關鍵字來訪問 C# 和 Java 中的非靜態成員。

Answer 8

最重要的是選擇一個標准並堅持下去。 退房■設計的C＃編碼標准在■設計（這是在右邊的鏈接）。 這是一個很棒的文檔，涵蓋了命名指南之類的內容。 他們建議對局部變量和方法參數使用駝峰式大小寫。

Answer 9

我們使用StyleCop來強制整個代碼的一致性。 在 Microsoft中使用StyleCop 強制執行一組通用的最佳實踐，用於 C# 源代碼的布局、可讀性、可維護性和文檔。

您可以在構建時運行 StyleCop 並讓它為樣式違規生成警告。

要回答您的具體問題，私有字段應采用駝峰式大小寫並以“this”為前綴。

Answer 10

我用來區分私有類變量和方法參數的約定是：

private string baseName;
private string prefixName;
private string suffixName;

public GameItem(string baseName, string prefixName, string suffixName)
{
    this.baseName = baseName;
    this.prefixName = prefixName;
    this.suffixName = suffixName;
}

Answer 11

我對此也有疑問，然后我決定檢查 Microsoft 的 github 代碼。 我看過的幾乎所有源代碼都對私有字段使用下划線。

https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/文檔似乎沒有提到這種用法。

Answer 12

按照 Microsoft 的命名約定，私有字段應以下划線為前綴。

例如：

private int _myValue;

祝你好運！

Answer 13

看看 ReSharper。 它將在您的名字不符合普通准則的所有地方下划線，您可以對其進行自定義。 另外，當然還有大量其他生產力增強。

Answer 14

我用 VB 做的比 C# 多得多，所以我想我將一些實踐（偏見？）從前者帶到了后者。

我喜歡性質的私人領域擁有領先的下划線-尤其是在C＃中，由於區分大小寫（？他們的想法是，反正），並以“M”，以及加強其范圍我前綴模塊/寬類變量.

如果你不喜歡那樣，你真的不會喜歡這個：我通常也使用類型前綴（屬性字段除外）——“o”代表對象，“s”代表字符串，“i”代表整數，等等.

我真的不能用同行評審的論文或任何東西來捍衛這一點，但它對我們有用，意味着我們不會被大小寫或字段/參數混淆所絆倒。

所以 ...

Class MyClass

    Private msClassVariable  As String = ""

    Private _classProperty As Integer = 0
    Property Readonly ClassProperty() As Integer
        Get
            Return _classProperty
        End Get
    End Property

    Sub New()

        Dim bLocalVariable As Boolean = False
        if _classProperty < 0 Then _classProperty = 0
        msClassVariable  = _classProperty.ToString()
        bLocalVariable = _classProperty > 0
    End Sub

End Class

Answer 15

就個人而言，我通過前綴“the”修改參數名稱，例如 theSamplingRate。 對我來說，這很有意義:)

Answer 16

我這樣做； 它非常符合MSDN。

class MyClass : MyBaseClass, IMyInterface
{
    public event EventHandler MyEvent;
    int m_MyField = 1;
    int MyProperty {
        get {
            return m_MyField;
        }
        set {
            m_MyField = value;
        }
    }

    void MyMethod(int myParameter) {
        int _MyLocalVaraible = myParameter;
        MyProperty = _MyLocalVaraible;
        MyEvent(this, EventArgs.Empty);
    }
}

這里有更多細節： http : //jerrytech.blogspot.com/2009/09/simple-c-naming-convention.html

Answer 17

private string baseName; 
private string prefixName; 
private string suffixName; 

public GameItem(string _baseName, string _prefixName, string _suffixName) 
{ 
    this.baseName = _baseName; 
    this.prefixName = _prefixName; 
    this.suffixName = _suffixName; 
}