2009-01-21 40 views
2

已通讀MSDN naming guidelines並找不到明確的答案,除此之外,您應儘量避免使用下劃線。比方說,我有以下幾點:在C#中,什麼是普遍接受的方式來引用類中的成員屬性?

public class Employee 
{ 
    private string m_name; //to store property value called Name 

    public string Name 
    { 
     get { return m_name; } 
     set { m_name = value; } 
    } 

    public void ConvertNameToUpper() 
    { 
     //by convention should you use this 
     return m_name.ToUpper(); 

     //or this 
     return Name.ToUpper(); 
    } 
} 

什麼是在上面m_name正確的命名約定?例如,在代碼我繼承我通常看到:

  • m_name
  • _name
  • 名稱
  • MYNAME或一些其它隨機標識符

哪一個(或另一)是最普遍接受?

作爲後續,在類的方法中,是指內部(私有)標識符還是公共屬性訪問器?

+3

的m是跛,它是從C結轉++。它沒有增加任何價值。如果你打算使用任何東西,請使用下劃線。 – 2009-01-21 20:57:54

+0

這應該是一個wiki – 2009-01-21 21:06:10

回答

14

我認爲,無論您使用什麼命名約定,最重要的是您保持一致。 我的意思是,如果你選擇像_name這樣的私人成員,那麼總是這樣做,而不是一次使用_name,而其他時間m_name。 我個人使用下劃線前綴約定。 (原因之一是因爲我使用NHibernate的,和NHibernate有一個「field.camelcase下劃線」訪問策略

對於你的另一個問題:。 這取決於你想要做什麼
請問您的屬性包含額外的邏輯,你是否希望當你引用它時執行這個邏輯?然後使用這個屬性。你不想執行這個邏輯?使用這個字段。 Eric Lippert在他的博客上寫了一個post關於這個

爲了您的目的:這一切都取決於具體情況。 如果您的財產包含一些額外的邏輯,並且您不想執行額外的邏輯whe n從類內訪問,然後使用後臺...

5

首先 - 對於簡單的get/set情況,我會建議您使用自動實現的屬性。如果你這樣做,編譯器將生成基礎變量,並且只引用屬性本身。

除此之外,我建議你選擇上述之一或類似的東西,只是堅持。我工作的公司使用vName,其中「v」表示這是該屬性的值。

+0

取決於正在使用的C#版本。我認爲自動屬性只能從C#3.0+中獲得。 – 2009-01-21 21:03:16

3

我在示例代碼中看到的最常見的是一個簡單的_前綴。

然而,真正重要的是團隊同意標準是什麼並堅持它。

2

如果您不能使用自動實現的屬性作爲布賴恩拉斯穆森建議,你必須有一個私人成員,那麼我會推薦下劃線前綴, _名稱。

在intellisense中,由於它們都具有相同的符號(藍色立方體),因此它不是一個顯而易見的項目是參數,本地還是私人成員。但是,如果您將光標移動到特定的項目,那麼工具提示會告訴您它們是哪一個。

我找到了下劃線前綴是一個方便的助視器,這使得它立即明顯,這是無需移動光標的私有成員。

0

一方面我同意你應該使用公司標準,另一方面我會盡量遵守行業標準。

0

我要重申以前的答案中,你應該與您的團隊使用,或者如果你是不是在一個團隊中,與不管你做什麼用一致的方式堅持。

就我個人而言,我使用下劃線前綴,因爲我發現它給了我一個很好的視覺提示。

0

我認爲一般公認的命名約定只是爲了使名稱有意義(而且代碼乾淨簡單)。在我看來,如果我的代碼中的標識符出於任何原因需要視覺提示,它太複雜了,名稱通常不完全準確。

我的代碼,需要手動剛讀......「M」的含義類級別,「P」指參數等的命名約定的開發,使代碼更容易閱讀,但它的工作最終做了恰恰相反的事情,因爲開發人員認爲「好」命名約定意味着可讀代碼。

只要確保這個丹尼斯·格林(前亞利桑那紅雀主帥)報價適用於您的標識:「他們是誰,我們認爲他們是」

0

我試圖只在必要時訪問成員變量,比如屬性是隻讀的,或者我想繞過任何設置邏輯。

這樣做的一個原因是,如果您稍後將邏輯添加到setter中,那麼您很可能希望它在任何地方都可以使用。

1

我曾經是非常反對「_」前綴,但它確實是有智能感知有用,當你想快速訪問成員字段,而不必鍵入很多信。

0

對於類級變量,我們的編碼標準表示使用mVariableName或m_VariableName。主要的是要跟隨你的公司/老師/等。編碼標準/實踐。

我個人而言,只有通過它的getter/setter訪問變量(如果有的話)。即使該變量僅在類中內部使用,我也使用自動屬性。這樣,我添加了一層abstaction,意味着更少的代碼來重構,如果我改變了一些東西。

順便說一句,你void函數不能返回一個字符串..... :-)

4

我使用的強制執行代碼一些風格樣式警察。我覺得這非常有用,我所有的團隊成員也使用它。

雖然有周圍使用樣式警察的大討論中,有一件事我會建議是,如果你使用的樣式警察說是給所有的樣式啓用。通過這種方式,當你在用戶之間分享時,它使事情變得更容易。

這個信息的一個特點是你不能用下劃線來命名你的私人領域。

private string name; 
public string Name 
{ 
    get { return this.name; } 
    set { this.name = value; } 
} 

風格締約方會議還強制使用的this.這讓事情變得更容易閱讀:所以我寫私有字段,然後PascalCase當公共屬性一般採用駝峯。

0

我只是想補充的是,MSDN命名規則沒有規定這一點,因爲它只有在公共接口準則(即屬性名稱,公共方法,公共方法的參數,等等),他們不關心關於私人會員的風格,所以就微軟而言,你可以使用任何你和你的團隊想要的。

0

首先,我和許多其他我曾與有使用前綴私有成員「M_」的廢除工作。接下來,每當我引用類中的私有成員時,我通常在「this.privateMemberVariableName」中使用this這個詞。使用它足以區分變量不是局部變量還是作爲方法內的參數傳遞的變量。

我指的是公共財產的名稱,如果它包含的邏輯是不是僅僅指的是私有成員變量,實例化等連接或保存在視圖狀態屬性值等。

0

framework Design guidelines book表示你不應該在變量前面加上_前綴 - 你應該使用小寫字母作爲變量的名字,Code Complete 2nd edition我相信你不應該用m_前綴變量。

相關問題