摘要：由于最近在做重构的项目，所以对重构又重新进行了一遍学习和整理，对31天重构最早接触是在2009年10月份，由于当时没有订阅Sean Chambers的blog，所以是在国外的社区上闲逛的时候链接过去的。记得当时一口气看完了整个系列并没有多少感觉，因为这些基本上项目都在使用，只是我们没有专门把它标示和整理出来，所以也没有引起多大的重视。现在突然接手这个重构项目，由于团队成员技术和经验参差不齐，所以有必要专门整理一个重构的纲要，当然这个系列也非常适合做新系统的代码规范参考，只要有代码的地方，这个重构规范就很有价值。周末也不想出去闲逛，因为在刚到这个美丽的城市，没有亲戚或者朋友，所以才能静下心来两天时间写完这个重构参考规范。同时也感受了Windows Live writer写文章的快感。当然重构的整体架构得另当别论（整体架构在我的这篇文章有专门的讲解（http://www.cnblogs.com/zenghongliang/archive/2010/06/23/1763438.html）。大的架构设计好了以后，这些重构细节点就成了东风之后的大火，对整个项目也是至关重要。31天重构这个系列和《代码大全》、《重构：改善既有代码的设计》比较起来最大的特点就是比较简单、浅显易懂。那么我这些文章也都是学习Sean Chambers的31天重构的笔记整理，所以如果大家对这个笔记有任何异议也可以指出。

具体也可以通过http://www.lostechies.com/blogs/sean_chambers/archive/2009/07/31/31-days-of-refactoring.aspx查看原文。

概念：本文中的”避免双重否定”是指把代码中的双重否定语句修改成简单的肯定语句，这样即让代码可读，同时也给维护带来了方便。

正文：避免双重否定重构本身非常容易实现，但我们却在太多的代码中见过因为双重否定降低了代码的可读性以致于非常让人容易误解真正意图。存在双重否定的代码具有非常大的危害性，因为这种类型的代码容易引起错误的假设，错误的假设又会导致书写出错误的维护代码，最终会导致bug产生。具体可以看下面的代码：

using  System.Collections.Generic;using  LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.After;

namespace  LosTechies.DaysOfRefactoring.SampleCode.DoubleNegative.Before{public class  Order{public void  Checkout(IEnumerable<Product> products, Customer  customer)        {if  (!customer.IsNotFlagged)            {// the customer account is flagged                // log some errors and returnreturn;            }

// normal order processing}    }

public class  Customer{public decimal  Balance { get; private set; }

public bool  IsNotFlagged        {get  { return  Balance < 30m; }        }    }}

如上代码中的双重否定可读性非常低，因为我们很难搞明白双重否定的正确值。要重构它也非常容易，如下是重构后的代码：

using System.Collections.Generic;using LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.After;

namespace LosTechies.DaysOfRefactoring.SampleCode.DoubleNegative.After{public class Order{public void Checkout(IEnumerable<Product> products, Customer customer)        {if (customer.IsFlagged)            {// the customer account is flagged                // log some errors and returnreturn;            }

// normal order processing}    }

public class Customer{public decimal Balance { get; private set; }

public bool IsFlagged        {get { return Balance >= 30m; }        }    }}

总结： ”双重否定“很容易让人产生错误的判断，也很难让人理解你的代码，所以这个重构在我们的代码中是很重要的，尤其是在判断条件很多且业务复杂的时候。

原文链接： http://www.cnblogs.com/KnightsWarrior/archive/2010/06/29/1767510.html