Question

作为一个独立商店的年轻（ish）开发人员，我非常欣赏Resharper作为学习工具和mini-QA。话虽这么说，Resharper在某些情况下可能会破坏你的代码（可能是边缘）？

例如（见下文），R＃不断暗示我的 - ＆gt;

this. is redundant 和 catch is redundant

还有其他一些例子，但我并没有像一般情况那样询问具体实例。

有没有人有R＃建议打破他们的代码？如果是这样的话，对我来说最重要的是什么呢？我能找到什么才能理解它是否真的给了我不好的建议？

 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;
        }
    }

Answer 1

捕获你的异常只是为了抛出它当然是多余的，在这种情况下与'this'相同。

如果你抓住它时实际做了什么，而不是重新抛出它，那么捕获将不再是多余的。

Answer 2

在我看来，Resharper需要被视为您对C＃的个人知识和软件开发原则的扩展。如果你看一个建议的R＃重构并且不理解它建议将它改为的代码......不要那样做。

Resharper可能（根据我的经验）是正确的，但如果它将你的代码改为你不理解的东西并且不能轻易阅读那么它不会给你任何好处。

我建议研究它建议使用的代码和概念，并努力了解该工具建议您做什么。只有这样，你才能判断一个给定的建议是否适用于你的情况。

如果您继续这样做并使用该工具来提升您的知识，那么最终R＃将开始作为您编写软件时温和提醒最佳实践和编码技术。

理想情况下，您使用该工具的次数越少，您应该依赖它就越少，因为您应该开始将这些概念合并到代码的第一遍中，并且应该首先停止需要它给出的建议。

Answer 3

ReSharper并非绝对可靠。与你坐在那里的人不一样，阅读你的代码。它尽力而为。也就是说，R＃的收益远大于损失，没有人应该盲目跟随R＃的建议。

R＃曾经建议改变我的代码肯定会破坏。我（有点伪代码）：

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

R＃告诉我将它包装在using中。这样做会在我完成其范围之前破坏我的按钮控件。当然，它比我自己的错误少了R＃，但是你去了。

Answer 4

ReSharper并不完美（与所有软件一样）。它肯定有错误，偶尔会提供不正确的建议，并会破坏您的代码。但是我发现这些非常罕见，通常涉及一些非常嵌套的通用场景。

一般情况下，如果ReSharper建议它是正确的。在这种情况下，ReSharper是正确的，因为catch语句实际上什么都不做。没有异常目标的抛出将重新抛出原始对抛出新异常，因此应该没有可见的副作用。

Answer 5

当然！您可以使用它来重构和破坏您的代码。您可以使用它通过解决方案重命名某些内容并让它破坏您的代码。这里的关键是resharper并没有真正打破你的代码...但你不恰当地使用它当然可以！我从来没有遇到任何破坏我的代码的建议的任何问题。您可以通过选项面板关闭resharper的几乎所有功能！

Answer 6

你唯一能够了解你应该和不应该注意的建议的方法是通过经验。

就个人编码风格而言，我喜欢将所有成员变量称为this.something，因为在浏览代码时更容易识别成员变量与本地字段，其他人可能因不同原因而不同意。

此外，抓住并重新抛出相同的异常不仅是多余的，而且实际上可能是一个非常糟糕的主意，因为捕捉和重新投掷不与首先没有捕获相同，并且可以打破你的电话堆栈。见http://weblogs.asp.net/fmarguerie/archive/2008/01/02/rethrowing-exceptions-and-preserving-the-full-call-stack-trace.aspx

Resharper听起来像是一个很好的指出可能性的工具，但你不应该把所有的建议都用于福音。我发现偶尔发生的事情让我意识到为什么我正在使用的编码练习是一个坏主意 - 比如丢失堆栈跟踪。但最终我不会太担心，因为这样的事情只能来自经验。

Answer 7

您获得的建议是ReSharper建议的默认设置。然而，我发现很多建议与我的正常编码方式不一致，所以我禁用它。您可以在同一个地方使用ReSharper建议轻松禁用它。

有关重构的好处是，有时您不会意识到一些新的C＃3.0功能可以简化您的代码，而ReSharper在这方面非常有用（请您使用Lambda表达式而不是匿名方法....）

Answer 8

我喜欢Resharper，但是它可以破坏你的代码。这恰好发生在我身上：

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

但Resharper希望我将lambda转换为方法组，如下所示：

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

Here's why it doesn't work这不是Resharper的错，但你还是要小心。

Answer 9

它肯定会破坏您的代码，但它总是先警告您可能存在的问题。您可以通过禁用其建议来弯曲resharper。我已经使用它多年了，当我在文本编辑器的右上角看到绿色矩形时，我感到很放松：）

Answer 10

我遇到的最大问题是当我进行重构时它并没有在任何地方生效。这发生在一个大型项目中，在任何给定时间我可能没有将所有引用组件加载到单个解决方案中，或者当我从距离声明相当远的位置进行重新构建时。小心点，你会没事的。

Answer 11

当它建议使用对象初始化程序时，它愿意做以下事情：

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

我实际上没有编译这个以查看编译器是否可以实际看到Name是一个与Name不同的变量，因为即使它有效，我发现它是不可接受的。

Answer 12

是的，这是我今天遇到的一个示例，其中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。

可以重新破坏你的代码吗？

12 个答案: