可以resharper打破你的代碼？

作爲一個獨立商店的年輕（ISH）開發者，我非常感謝Resharper作爲學習工具和迷你QA。這就是說，Resharper在某些情況下可能會破壞你的代碼（可能是邊緣）？可以resharper打破你的代碼？

例如（見下文），R＃不斷暗示我 - >

this. is redundant和catch is redundant

還有其他的例子還有，但我不是問一個具體的實例作爲多如一般情況。

有沒有人有過R＃暗示break他們的代碼？如果是這樣，他們和mabye對我來說最重要的是什麼？爲了理解它是否實際上給了我不好的建議，我可以尋找什麼？

private void LoadMyForm(DataRow row) 
    { 

     try 
     { 
      this.tbxFirstName.Text = row["FirstName"].ToString(); 
      this.tbxLastName.Text = row["LastName"].ToString(); 
      tbxMiddleName.Text = row["MiddleName"].ToString(); 
      tbxPersonID.Text = row["PersonID"].ToString(); 
      tbxSSN.Text = row["SSN"].ToString(); 
      tbxEmailAddress.Text = row["EmailAddress"].ToString(); 
     } 
     catch (Exception) 
     { 
      throw; 
     } 
    }

來源

2009-06-12 Refracted Paladin

這在這裏是多餘的，一個簡單的拋出是一件壞事，你正在吞噬堆棧跟蹤的原始錯誤，但在過程中沒有增加任何值。 – 2015-09-30 01:29:26

在我看來，Resharper需要被視爲您個人對C＃和軟件開發原則的個人知識的擴展。如果你看看一個建議的R＃重構，並且不理解它建議將其改爲......不要這樣做的代碼。

Resharper可能（根據我的經驗）是正確的，但如果它將要改變你的代碼變成你不明白，並且不容易閱讀的東西，那麼它不會對你有任何幫助。

我會推薦研究代碼及其建議使用的概念，並努力瞭解該工具建議您執行的操作。只有這樣，你才能判斷一個給定的建議是否適用於你的情況。

如果您繼續這樣做，並使用該工具進一步提高您的知識水平，那麼最終R＃將開始作爲您編寫軟件時最佳實踐和編碼技術的溫柔提示。

理想情況下，使用該工具的越多，就越應該依賴它，因爲您應該開始將這些概念合併到代碼的第一遍中，並且應該停止需要首先提供的建議。

來源

2009-06-15 14:56:54

當然！你可以用它來重構和破壞你的代碼。你可以用它來通過你的解決方案重命名一些東西，並讓它破壞你的代碼。這裏的關鍵是，resharper並不是真的會打破你的代碼......但是你的使用不當當然可以！我從來沒有任何關於破壞我的代碼的建議的問題。您可以通過選項面板關閉resharper的幾乎所有功能！

來源

2009-06-12 18:52:03

真的嗎？它無數次地破壞了我們的代碼。不過，更多的情況是通過快速修復而不是重構。 – 2010-07-24 00:56:51

僅僅抓住你的異常來拋出它肯定是多餘的，在這種情況下與'this'相同。

如果你在抓到它時確實做了某些事情，而不是重新拋出它，捕獲將不再是多餘的。

來源

2009-06-12 18:54:00

另外，捕獲所有異常是一個_bad_想法，除了非常有限的情況。 – Talljoe 2009-06-12 19:01:49

好點，非常真實。捕獲特定的預期異常並處理這些異常。其他任何東西都不應該被抓到。 – 2009-06-12 19:06:15

您得到的建議是ReSharper建議的默認設置。 Howerver，我發現很多建議都不符合我正常的編碼風格，所以我禁用它。您可以在同一地點使用ReSharper建議輕鬆禁用它。

重構的好處在於，有時您並不知道一些新的C＃3.0功能可以簡化您的代碼，並且ReSharper在這方面非常有用（請問您使用Lambda表達式而不是匿名方法.... ）。

來源

2009-06-12 18:55:29

它肯定會破壞你的代碼，但它總是首先警告你可能出現的問題。您可以通過禁用其建議來讓resharper符合您的意願。我已經使用了好幾年了，當我看到我的文本編輯器右上角的綠色矩形時，我有點放鬆了:)

來源

2009-06-12 18:55:48 idursun

ReSharper並不完美（就像所有軟件一樣）。它肯定有錯誤，偶爾會提供不正確的建議，並會破壞你的代碼。不過，我發現這些非常罕見，通常涉及一些非常嵌套的通用場景。

一般來說，如果ReSharper建議的東西是正確的。在這種情況下，ReSharper是正確的，因爲catch語句實際上什麼都不做。沒有異常目標的拋出將會重新拋出原始的拋出一個新的異常，因此應該沒有可見的副作用。

來源

2009-06-12 18:56:20 JaredPar

我曾經遇到的最大的問題是，當我做一個重構，它不應該在任何地方生效。這發生在一個大型項目中，我可能沒有在任何給定的時間將所有引用組件加載到單個解決方案中，或者當我正在從與聲明相距較遠的位置進行refectoring時。只是要小心，你會沒事的。

來源

2009-06-12 19:00:50 captncraig

ReSharper並非萬無一失。這與坐在你身邊的人讀取你的代碼不一樣。它盡力而爲。也就是說，R＃的收益遠大於虧損，沒有人應該盲目遵循R＃的建議。

R＃曾經建議改變我的代碼，肯定是破了。我有（有些僞代碼）：

var submitBtn = (Button)Controls.FindControl(blahblahblah);

R·告訴我它包裝在一個using。這樣做會在我完成其範圍之前破壞我的按鈕控制。當然，這不是R＃的錯誤，而是我自己的錯誤，但是那裏還是有。

來源

2009-06-12 19:01:25

只有通過經驗，你才能瞭解你應該和不應該注意的建議的唯一方法。

個人作爲編碼風格，我喜歡將所有成員變量稱爲this.something，因爲它可以在查看代碼時更容易識別成員變量與本地字段，但其他人可能因不同原因而不同意。

此外，捕獲和重新拋出同樣的異常不僅是多餘的，但實際上可能是一個非常糟糕的主意，因爲趕上並重新投擲是不一樣擺在首位不醒目，而且可以打破你的調用堆棧。請參閱http://weblogs.asp.net/fmarguerie/archive/2008/01/02/rethrowing-exceptions-and-preserving-the-full-call-stack-trace.aspx

Resharper聽起來像是指出可能性的好工具，但您不應該接受福音的每一個建議。我發現偶爾會發生一些事情，這讓我意識到爲什麼我使用的編碼練習是一個糟糕的主意 - 例如丟失堆棧跟蹤。但是，最終我不會太擔心，因爲這樣的事情只能來自經驗。

來源

2009-06-15 15:27:28 Justin

我愛resharper，但是它可以打破你的代碼。這只是發生在我身上：

new string[]{"Some+Nested+Type"}.Select(x => Type.GetType(x)); // this works

但ReSharper的希望我的拉姆達轉換爲方法組，像這樣：

new string[]{"Some+Nested+Type"}.Select(Type.GetType); // this doesn't work

Here's why it doesn't work這不是ReSharper的錯，但你還是要小心。

來源

2014-01-04 19:59:15

當它建議使用對象初始化它願意做這樣的事情：

Foo ThisFoo = new Foo() {Name = Name;}

我還沒有實際編譯這個，看看如果編譯器實際上可以看到，名稱是比名稱不同的變量，因爲即使它作品我覺得它是不可接受的。

來源

2015-08-24 21:03:07

是的，這裏是我遇到了今天的一個ReSharper的建議引起了運行時異常的例子：

static void A() 
{ 
    B(null); 
} 

static void B(List<int> list) 
{ 
    C(() => list.Sort()); 
} 

static void C(Action action) 
{ 
}

ReSharper的建議我換方法B的內容：

C(list.Sort);

看起來像一個合理的改變，但由於可怕的代碼調用它，它實際上導致了一個System.ArgumentException。

來源

2015-11-24 16:41:30 hypehuman

可以resharper打破你的代碼？

回答

相關問題