您的團隊是如何爲.Net獲得好結果而自定義Stylecop（以及其他工具）？

Question

我們的團隊仍然處於愛/恨的關係。我希望通過對應該排除哪些規則以及應該添加哪些規則進行內部投票來結束辯論。

在這樣做之前，我想問問他人SO用戶。標準化（但不限制）回覆：

1. 您目前的StyleCop版本是什麼？
2. 你目前的目標是什麼.Net版本？
3. 您關閉了哪些默認規則？
4. 您打開了哪些非默認規則？
5. 你編碼自己的規則？請描述。
6. 你有任何其他StyleCop技巧值得分享？
7. 你使用Resharper嗎？什麼版本？對於降壓來說這是一個好消息嗎？
8. 您是否使用了與Visual Studio集成並輔助開發的.Net/C++的其他工具？你有錢了嗎？
9. 還有什麼你想補充的？
10. ...

謝謝！

Answer 1

1. 我在4.3.3.0
2. .NET 3.5
3. 地段，所有的文檔和其他人的集合。
4. 無，IIRC。
5. 在過去，我做過。我目前沒有編碼風格要求，但以前我做過。我有它們時爲它們創建自定義規則。
6. 「右鍵單擊警告，顯示錯誤幫助」是一個好主意。我最喜歡的是「將Settings.StyleCop文件添加到解決方案項目文件夾」。
7. 不，但我會盡我所能。
8. FxCop。是的，錢的價值無限。
9. 是的。您啓用/禁用的規則應完全由您嘗試驗證的編碼準則來驅動。你不知道使用哪個的原因很可能是因爲你沒有。所以這是你應該做的第一件事，創建一套編碼準則。您可以使用StyleCop來確定要執行的規則（從所有規則開始並在每個人都同意該規則不會爲解決該規則所付出的努力提供任何價值時將其刪除）。這看起來有點落後，並且會忽略了一種編碼標準的可能性，這個標準還沒有被StyleCop強制執行，但肯定比沒有好。這將是一個快速生成一些本地標準的方法。另一種方法是環顧一下existing published coding guidelines，你的團隊可以或多或少地同意（1），然後配置StyleCop來強制執行這些。無論哪種方式，在整個團隊中使用一致的編碼風格都有很多好處，而StyleCop則是實施它的方式。
10. 自定義規則真棒。不要打折關閉StyleCop規則並實現相同規則的「更好」版本的可能性。

（1）這就像比薩配料，也沒有辦法，你將獲得該組中的完全一致，但一個普遍的共識可能出現

Answer 2

1. 你目前的版本StyleCop的？ 4.3.3本地，4.3.0構建服務器
2. 什麼.NET版本你目前的目標呢？ 2.0或3.5
3. 您關閉了哪些默認規則？ 無
4. 您打開了哪些非默認規則？ 只是增加了幾個例外的匈牙利規則
5. 已經編寫你自己的規則？請描述。 nope
6. 您是否有任何其他StyleCop技巧值得分享？ 在項目中使用的文件
7. 你使用ReSharper的的<ExcludeFromStyleCop> element？什麼版本？對於降壓來說這是一個好消息嗎？ 是的，R＃5，很有價值（特別是與StyleCop for ReSharper）
8. 您是否使用任何其他工具與.Net/C++集成Visual Studio並協助開發？你有錢了嗎？ GhostDoc是唯一的其他工具，我們使用

Answer 3

1. 4.3.3
2. .NET 3。5
3. 熄滅SA1309 - FIELDNAMES不能以下劃線開始（對於物業
4. 自定義規則背後的私有變量沒有變量開始以「M_」
5. 是的，在＃4自定義規則基於斷碼在此blog
6. 沒有真正
7. 沒有
8. 我們使用的VisualSVN插件，它是免費的，我們發現它很有用，因爲我們使用Subversion進行源代碼控制