我們應該在成熟的項目中開始使用FxCop和/或StyleCop嗎？

Question

我們有3年的解決方案（.sln），大約有20個項目（.csproj）。 開始使用FxCop和/或StyleCop是否合理？ 也許我們應該首先將它用於幾個小項目但不是整個解決方案？

看到一些經驗豐富的答案會很高興。

謝謝。

編輯：我們正在使用TeamCity進行持續集成。 我們沒有可能使用ReSharper。 :(僅限CodeRushXpress。

Answer 1

是的，你應該，但慢慢來。

獲取ReSharper的副本，安裝StyleCop，獲取StyleCop for ReSharper插件，設置你想要使用的規則，從那時起，你打開的每個文件都會充滿搖擺的藍線，告訴你哪里有壞事。

如果你只修復它們，一次一個文件，你最終會得到一個很好的干凈項目，而不需要說服你的老板讓你花3個星期的時間來完成你的項目，什么都不會導致可以節省時間！

獲得干凈的代碼就像重構一樣，如果你嘗試一次完成整個項目，那么你最終會陷入困境:)

Answer 2

FxCop / StyleCop的替代或補充是使用商業工具NDepend 。 使用此工具，可以通過LINQ查詢 （即CQLinq） 編寫代碼規則 。 免責聲明：我是該工具的開發人員之一

默認提出了200多個代碼規則 ，包括設計 ， 體系結構 ， 代碼質量 ， 代碼演變 ， 命名約定 ， 死代碼 ， .NET Fx使用 ......

CQLinq專門編寫可以在Visual Studio中實時驗證的代碼規則，或者可以在構建過程中驗證並在HTML / javascript報告中報告的代碼規則。

與FxCop或StyleCop相比，CQLinq的優勢在於可以直接編寫代碼規則並立即獲得結果。 建議設施瀏覽匹配的代碼元素。 具體來說，這看起來像這樣：

Answer 3

我剛開始在我的個人項目中使用StyleCop，並且需要花一點時間來解決所提出的“問題”。

我建議您在文件樣本上運行StyleCop並在啟動之前分析結果以進行任何更改。

例如，默認情況下，StyleCop會抱怨所有方法（公共和私有）缺少方法文檔。 現在，我無法為您解答這個問題，但是您需要決定是否希望私有方法擁有完整的文檔（兩種方式都有參數）。 但是你需要決定一種方式。 你不希望用一種方式進行6個月的改變，然后決定你想要另一種方式。 這要么是要引導你進行不必要的修改，要么必須重新審視你認為已經完成的代碼。

一旦你對StyleCop的設置做了必要的調整，然后讓你的代碼庫松散 - 一次一個項目。

Answer 4

關於FxCop，是的，使用該工具是一個好主意，無論您是在新項目還是現有項目中。 與StyleCop非常相似，您可以運行該工具並查看輸出。 與StyleCop不同，FxCop適用於編譯代碼，而不是源代碼。

一開始它可能會壓倒一切。 一個好主意是關閉所有規則組，然后重新運行該工具以獲得空白。 一次啟用一個組，解析顯示的任何消息，或者如果它們不適用於您，則關閉該組中的特定規則（默認規則作為一個整體非常廣泛，並非全部適用;您需要自定義規則集滿足您的需求）。

最后，您將通過實施適當的修補程序或有選擇地禁用無關的規則來解決所有消息。

作為一項規則（沒有雙關語）我認為安全和性能小組開始時是好的。 命名規則是主觀的，可能與您自己的約定沖突。 如果是這樣，請關閉它們。 流動性和全球化也是主觀的，取決於您的需求。 至於其余的，好吧，你創建自己的結論！

Answer 5

根據解決方案的創建方式，集成（以及這些工具報告的修復問題）可能需要花費大量時間，因此我認為逐個集成項目是您應該采用的方式。

編輯 ：

除了Ed Woodcock的回答：你可以配置SyleCop（我也打賭FxCop）在每個VS版本中自動運行他們的檢查。 使用此功能，您可以逐個啟用所有項目的檢查，並在常規開發期間修復所有警告（也可以配置這些工具以生成錯誤）。

Answer 6

這取決於：

• 更改為此工作的代碼沒有任何價值。
• StyleCop編碼樣式可能與當前代碼中的樣式不匹配。
• 如果您嘗試讓當前代碼通過FxCop和/或StyleCop，則可能會引入錯誤
• 很多FxCop規則很少或沒有價值，除非第三方再次編寫你的dll代碼。
• 如果您忽略了101個警告，那么使用檢查工具是沒有意義的，因為您永遠不會發現您關心的重要警告。

我認為它歸結為比獲得代碼的基地，通過檢查工具的成本維護當前的代碼庫的成本 可能降低。 更一致的代碼庫將具有更低的維護成本，但如果您對代碼庫進行了大量更改，那么這只是有價值的。