当你穿过它们时,你总是会重构哪些类型的编码反模式？

我刚刚重构了一些代码,这些代码位于我正在处理的类的不同部分,因为它是一系列嵌套的条件运算符(？:),它通过一个相当简单的switch语句(C#)变得更加清晰.

您何时会触摸不直接与您正在处理的代码以使其更清晰？

我曾经重构过,并遇到过像这样的代码:

string strMyString;
try
{
  strMyString = Session["MySessionVar"].ToString();
}
catch
{
  strMyString = "";
}

Resharper指出.ToString()是多余的,所以我把它拿出来了.不幸的是,最终破坏了代码.每当MySessionVar为null时,它都不会导致代码所依赖的NullReferenceException将其向下移动到catch块.我知道,这是一些可悲的代码.但我确实从中学到了很好的教训.不要快速浏览依赖于工具的旧代码来帮助您进行重构 - 通过自己来思考.

我的确最终重构如下:

string strMyString = Session["MySessionVar"] ?? "";

更新: 由于这篇文章正在被投票,从技术上讲不包含问题的答案,我想我应该回答这个问题.(好吧,让我感到困扰的是我实际上是在梦想它.)

我个人在重构之前问了几个问题.

1)系统是否受源代码控制？如果是这样,请继续进行重构,因为如果出现问题,您可以随时回滚.

2)是否存在我正在改变的功能的单元测试？如果是这样,太好了!重构.这里存在的危险是单元测试的存在并不表明所述单元测试的准确性和范围.良好的单元测试应该能够发现任何重大变化.

3)我是否完全理解我正在重构的代码？如果没有源代码控制和没有测试,我真的不明白我正在改变的代码,那就是一个红旗.在重构之前,我需要更加熟悉代码.

在#3的情况下,我可能会花时间实际跟踪当前使用我正在重构的方法的所有代码.根据代码的范围,这可能很容易或不可能(即,如果它是公共API).如果它归结为公共API,那么您真的需要从业务角度理解代码的原始意图.

如果测试已经到位,我只会重构它.如果没有,通常不值得我花时间编写测试和重构可能工作的代码.

这是一个小型的小型反模式,但它让我很恼火,每当我找到它时,我立即将其清除.在C(或C++或Java)中

if (p)
    return true;
else
    return false;

变

return p;

在Scheme中,

(if p #t #f)

变

p

在ML

if p then true else false

变

p

我看到这个反模式几乎完全是由本科生编写的代码.我绝对不会这样做!!

每当我遇到它并且我不认为改变它会导致问题(例如,我可以理解它,我知道它做了什么.例如,伏都教的水平很低).