為什么StyleCop建議使用“this”作為前綴方法或屬性調用？

Question

我一直在嘗試遵循StyleCop關於項目的指導原則，看看最終的代碼是否更好。 大多數規則都是合理的，或者是關於編碼標准的意見問題，但有一條規則令我感到困惑，因為我沒有看到其他人推薦它，而且因為我沒有看到明顯的好處：

SA1101：對{method或property name}的調用必須以'this'開頭。 前綴表示該項是該類的成員。

在缺點方面，代碼顯然更加冗長，遵循該規則有什么好處？ 這里有人遵循這條規則嗎？

Answer 1

除非我在您需要的場景中，否則我並不真正遵循此指南：

• 有一個實際的歧義 - 主要是這會影響構造函數（ this.name = name; ）或類似Equals東西（ return this.id == other.id; ）
• 您想要傳遞對當前實例的引用
• 您想要在當前實例上調用擴展方法

除此之外，我認為這個混亂。 所以我關閉規則。

Answer 2

它可以使代碼一目了然。 當你使用this ，它更容易：

• 告訴靜態和實例成員分開。 （並將實例方法與代表區分開來。）
• 區分實例成員與局部變量和參數（不使用命名約定）。

Answer 3

我認為這篇文章解釋了一下

http://blogs.msdn.microsoft.com/sourceanalysis/archive/2008/05/25/a-difference-of-style.aspx

...微軟的一位傑出的年輕開發人員（好吧，是我）決定自己編寫一個小工具，可以檢測團隊中使用的C＃風格的變化。 StyleCop誕生了。 在接下來的幾年里，我們收集了微軟各個團隊可以找到的所有C＃風格指南，並挑選出這些風格常見的所有最佳實踐。 這些形成了第一組StyleCop規則。 這項工作產生的最早規則之一是使用此前綴來調用類成員，並從字段名稱中刪除任何下划線前綴。 C＃風格已經正式與舊的C ++部落分開。

Answer 4

this.This 
this.Does 
this.Not 
this.Add 
this.Clarity 
this.Nor 
this.Does 
this.This 
this.Add 
this.Maintainability 
this.To 
this.Code

使用“this。”，當過度使用或強制樣式要求時，只不過是一種偽裝的設計，即只有1％的開發人員真的不理解代碼或他們正在做什么，並使其成為現實。 99％想要編寫易於閱讀和維護的代碼的人很痛苦。

一旦你開始輸入，Intellisence將列出你輸入的范圍內可用的內容，“這個”。 沒有必要公開班級成員，除非你完全不知道你編碼的是什么，否則你應該能夠輕松找到你需要的項目。

即使你完全無能為力，也要使用“這個”。 提示可用的內容，但不要將其留在代碼中。 還有一些像Resharper這樣的附加組件有助於提高范圍的清晰度並更有效地暴露對象的內容。 最好學習如何使用提供給你的工具，然后養成一個被大量同事討厭的壞習慣。

任何不能理解靜態，本地，類或全局內容范圍的開發人員都不應該依賴“提示”來指示范圍。 “這個。” 比匈牙利符號更糟糕，因為至少匈牙利符號提供了關於變量引用的類型的想法，並提供了一些好處。 我寧願看到“_”或“m”用於表示類字段成員然后看到“這個”。 到處。

我從來沒有遇到任何問題，也沒有看到同事開發人員的問題，他們反復與代碼范圍爭吵或編寫因為不使用“this”而總是錯誤的代碼。 明確。 “這就是”毫無根據的恐懼。 防止未來的代碼錯誤，並且通常是在無知被重視的地方使用的論據。

編碼人員隨着經驗增長，“這個”。 就像要求某人將訓練輪放在自行車上作為成年人一樣，因為這是他們首先必須學習如何騎自行車。 成年人可能會在1000次騎車時從自行車上掉下來，但是沒有理由強迫他們使用訓練輪。

“這個。” 應該禁止使用C＃的語言定義，遺憾的是使用它只有一個原因，那就是解決歧義，這也可以通過更好的代碼實踐輕松解決。

Answer 5

請注意，編譯器不關心是否this引用前綴（除非名稱與本地變量和字段沖突，或者您想在當前實例上調用擴展方法。）

這取決於你的風格。 我個人刪除了this. 從代碼中我認為它會降低信噪比。

僅僅因為微軟在內部使用這種風格並不意味着你必須這樣做。 StyleCop似乎是一個公開的MS內部工具。 我全都是為了遵守微軟關於公共事物的慣例，例如：

• 類型名稱在PascalCase中
• 參數名稱在camelCase中
• 接口應以字母I為前綴
• 使用單數名稱作為枚舉，除了它們是[標志]

...但是，在您的代碼的私有領域中發生的事情是私有的。 做你的團隊同意的任何事情。

一致性也很重要。 它在閱讀代碼時減少了認知負擔，特別是如果代碼風格符合您的預期。 但即使在處理外國編碼風格時，如果它是一致的，那么用它也不會花費很長時間。 使用ReSharper和StyleCop等工具可確保您認為重要的一致性。

使用.NET Reflector表明Microsoft無論如何都堅持使用BCL中的StyleCop編碼標准。

Answer 6

使用一些基本的原因this （和我不約而同地總是前綴類值與類的他們是一部分井的名字-甚至是類本身內）。

1）清晰度。 你知道在這個瞬間你在類定義中聲明了哪些變量，以及你聲明為locals，參數和諸如此類的變量。 在兩年內，你將不會知道這一點，你將繼續進行重新發現的奇妙之旅，這絕對是毫無意義的，如果你事先明確表示父母的話，則不需要。 處理代碼的其他人從一開始就不知道，因此立即受益。

2）智能感知。 如果輸入'this'。 您將獲得幫助中所有特定於實例的成員和屬性。 這使得查找事物變得更加容易，特別是如果你維護別人的代碼或代碼，你幾年后就沒有看過。 它還可以幫助您避免因誤解哪些變量和方法被聲明的位置和方式而導致的錯誤。 它可以幫助您發現在編譯器阻塞代碼之前不會出現的錯誤。

3）當然，你可以通過使用前綴和其他技術來達到同樣的效果，但是這就引出了一個問題，即為什么你會發明一種機制來處理問題，當有一種機制來構建這種語言時實際支持的語言。 IDE？ 如果您觸摸鍵入，即使在某種程度上，它也會最終降低您的錯誤率，因為不要強迫您將手指從原位移開以獲得下划線鍵。

我看到很多年輕的程序員通過不輸入一兩個字符而節省了大量時間。 大部分時間都花在調試上，而不是編碼。 不要太擔心你的打字速度。 擔心您能夠多快了解代碼中發生的事情。 如果你總共節省了五分鍾的編碼並且花了十分鍾的時間進行調試，那么無論你看起來多么快，你都會放慢速度。

Answer 7

我確實遵循它，因為我認為能夠分辨出對靜態和實例成員的訪問權限非常方便。

當然，我必須在構造函數中使用它，因為我通常給構造函數參數賦予與其值分配的字段相同的名稱。 所以我需要“這個”才能訪問這些字段。

Answer 8

此外，可以在函數中復制變量名稱，因此使用“this”可以使其更清晰。

class foo {
  private string aString;

  public void SetString(string aString){
    //this.aString refers to the class field
    //aString refers to the method parameter        
    this.aString = aString; 
  }
}

Answer 9

我主要是出於智能感知的原因。 輸入this.很好this. 並獲得屬性，方法等的consise列表