關於成員變量的C＃命名約定

Question

我在這里看到了一個關於SO的建議，沒有命名private/public成員變量，它們的區別僅在於第一個字符的情況。 例如：

private string logFileName;

public string LogFileName
{
    get
    {
        return logFilename
    ....

和： private System.Windows.Forms.MainMenu mainMenu;

和： DialogResult dialogResult = this.saveConfigFileDialog.ShowDialog();

和：

public Version Version
{
    get;
    set;
}

和：

    private void CheckPollingType(PollingType pollingType)
    {

那么，我聽錯了嗎？ 這些命名約定有什么問題嗎？ 如果是，那么有什么更好的方法呢？ 鏈接，參考是一個加號。

謝謝。

Answer 1

這絕對是一個非常流行的命名約定，我不明白為什么你應該反對它。

我只是建議遵循MSDN提供的C＃命名約定以及MSDN提供的 一般命名約定 。

具體來說，他們有關於屬性的說法：

使用名詞，名詞短語或形容詞命名屬性。

名詞短語或形容詞適用於屬性，因為屬性包含數據。

不要使用與Get方法名稱匹配的屬性。

例如，不要將屬性命名為EmployeeRecord，並將方法命名為GetEmployeeRecord。 開發人員不知道使用哪個成員來完成他們的編程任務。

使用肯定短語（CanSeek而不是CantSeek）命名布爾屬性。 或者，您也可以使用Is，Can或Has為布爾屬性添加前綴，但僅限於添加值的位置。

考慮給一個屬性與其類型相同的屬性。

當您具有強類型的枚舉屬性時，該屬性的名稱可以與枚舉的名稱相同。 例如，如果您有一個名為CacheLevel的枚舉，則返回其值之一的屬性也可以命名為CacheLevel。

我認為，如果有一個令人信服的理由反對你的建議他們會在他們的指導方針中提到它。

Answer 2

大多數時候，類級變量都以下划線為前綴。 所以myVariable實際上是_myVariable。 很多人不喜歡用一個字符來改變名字，因為它太容易犯錯。

做myVariable和MyVariable沒有任何問題。 這只是一個慣例，如果每個人都遵循它，那么它可能會工作得很好。

就個人而言，如果可能的話，我會免除私有變量，只需使用屬性中的getter和setter。 大多數時候（但不是所有時間），訪問私有變量用於不允許在屬性中進行寫訪問。
這可以通過以下方式解決：

public String MyVariable
{
   get;
   private set;
}

Answer 3

通常情況下，我總是看到私人成員領先_。 （假設它不是汽車財產）

private string _customerName;
public string CustomerName
{
    get{return _customerName;}
    set{_customerName = value;}
}

當然，最終的判決是你的團隊的慣例（假設你沒有做一個單獨的狼項目或與完全蠢貨一起工作）

Answer 4

我會用我一直用過的東西把帽子扔進戒指

class ClassName //Classes are PascalCase
{
    public ClassName(int myProperty) //Constructor arguments are named the same as the property they set but use camelCase.
    {
       _myProperty = myPropriety;
    }
    public void MyFunction(object varToBePassed) //Function names are PascalCase, passed pramaters are camelCase.
    {
        int sampleVar; //local variables are camelCase
    }
    public int MyProperty { get { return _myProperty; } } // Properties are PascalCase

    private int _myProperty; // Private fields are camelCase and start with a _

Answer 5

以下是微軟的權威指南。

如果您對.NET框架中使用的命名和樣式約定背后的細節和原因感興趣，我也會推薦本書。

請享用！

Answer 6

這些命名約定沒有任何問題。

根據.Net框架設計指南，屬性版本實際上是推薦的格式。

現場聲明同樣符合框架指南，因為它是基於camelCased。 關於變量是否應該以_或m_為前綴，偶爾會發生一些宗教戰爭。 這是一個需要在你的小組內解決的問題。

.Net框架設計指南適用於類型成員

• http://msdn.microsoft.com/en-us/library/ms229012.aspx

Answer 7

我可以認為不使用大小寫來區分公共成員和私有成員的一個原因是Visual Studio Intellisense會將兩個成員排在彼此旁邊，因此您可能會使用錯誤的成員而不會注意到。

話雖這么說，我使用你所描述的約定（用例來區分可訪問性）在我的代碼中，我沒有遇到任何問題。

Answer 8

您選擇的命名約定 - 保持一致。 那么至少當你在六個月后回到代碼中，或者當有人第一次看到它時，他們將能夠找出什么是什么。

Answer 9

但請注意這種情況：

public class MyClass {
    public int Foo { get; private set; }

    public MyClass(int foo) {
        // oops, setting the parameter to itself, not the property
        foo = foo;
    }
}

Visual Studio會警告你這種情況，但它不是非法的，有時會漏掉。

Answer 10

不同案例的同名主要問題是，並非.net中的所有語言都區分大小寫，即視覺基礎。

這是一個真實問題的唯一情況是，當您公開的成員僅根據具體情況而有所不同時。 可以設置兼容性屬性，以便編譯器告訴您是否有這樣的場景之一。

如上所述，這並不會真正影響支持私有成員的情況。

Answer 11

建議的命名約定的基本問題是Intellisense將使用屬性上的私有變量。 在許多情況下，這實際上並不是一個問題（事實上，通常是一件好事），但對於那些少數情況，將兩個名稱分開的約定是有用的。 我喜歡m_用於私有成員變量，c_用於私有靜態變量。

Answer 12

如果你只是做C＃這沒問題，但如果你（或你的團隊/公司）也在做VB.Net（不區分大小寫），那么我建議不要在C＃中做這個更好或者使不同語言之間的命名約定沒有太大差別。

Answer 13

我看到的兩個最受歡迎的約定是使用_或m_作為私有成員變量的前綴。 我個人更喜歡m_慣例，但只要它在整個項目/團隊中保持一致，我真的不在乎。 我不是一個進入'宗教戰爭'的人:)

Answer 14

由於這會在關於該主題的最頂層搜索結果中彈出，我也想分享我的建議：

除了公共/私有成員的Pascal / camelCase約定之外，我總是選擇由2個或更多單詞組成的成員變量名，以及由單個小寫單詞或甚至只是一個字母組成的局部變量名。

public class MyCanvas : Canvas {
    public int CanvasId { get; private set; }
    private double canvasHeight; // member vars consist of 2+ words
    private double canvasWidth;

    public MyCanvas(int id) {
        CanvasId = id;
        double height = ...; // local vars consist of one word/letter
        canvasHeight = height;
    }
}

這允許選擇一致且有意義的變量名稱，沒有像_這樣的“有趣”前綴，但也可以區分本地變量和成員變量。