作为一个独立商店的年轻(ish)开发人员,我非常欣赏Resharper作为学习工具和mini-QA.话虽这么说,Resharper在某些情况下可能会破坏你的代码(可能是边缘)?
例如(见下文),R#不断暗示我的 - >
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; } }
Chad Ruppert.. 13
只捕获你的异常肯定是多余的,在这种情况下与'this'相同.
如果你抓住它时实际做了什么,而不是重新抛出它,那么捕获将不再是多余的.
只捕获你的异常肯定是多余的,在这种情况下与'this'相同.
如果你抓住它时实际做了什么,而不是重新抛出它,那么捕获将不再是多余的.
在我看来,Resharper需要被视为您对C#的个人知识和软件开发原则的扩展.如果你看一个建议的R#重构并且不理解它建议将它改为的代码......不要那样做.
Resharper可能(根据我的经验)是正确的,但如果它将你的代码改为你不理解的东西并且不能轻易阅读那么它不会给你任何好处.
我建议研究它建议使用的代码和概念,并努力了解该工具建议你做什么.只有这样,你才能判断一个给定的建议是否适用于你的情况.
如果您继续这样做并使用该工具来进一步了解您的知识,那么最终R#将开始作为您编写软件时的最佳实践和编码技术的温和提示.
理想情况下,您使用该工具的次数越少,您应该依赖它就越少,因为您应该开始将这些概念合并到代码的第一次传递中,并且应该首先停止需要它给出的建议.
ReSharper并非绝对可靠.与你坐在那里的人不一样,阅读你的代码.它尽力而为.也就是说,R#的收益远大于损失,没有人应该盲目跟随R#的建议.
R#曾经建议改变我的代码肯定会破坏.我有(有点伪代码):
var submitBtn = (Button)Controls.FindControl(blahblahblah);
R#告诉我将它包装成一个using
.这样做会在我完成其范围之前破坏我的按钮控件.当然,它比我自己的错误少了R#,但是你去了.