代码规范

代码之丑（一）——让判断条件做真正的选择

if (0 == retCode) {
    SendMsg("000", "Process Success", outResult);
} else {
    SendMsg("000", "Process Failure", outResult);
}

看出来问题了吗？经过仔细的对比，我们发现，如此华丽的代码，if/else的执行语句真正的差异只在于一个参数。第一段代码，二者的差异只是发送的消息，第二段代码，差异在于最后那个参数。

看破这个差异之后，新的写法就呼之欲出了，以第一段代码为例：
Java代码  

String msg = (0 == retCode ? "Process Success" : "Process Failure");
SendMsg("000", msg, outResult);

由这段代码调整过程，我们得出一个简单的规则：

让判断条件做真正的选择。
对于前面调整的代码，判断条件真正判断的内容是消息的内容，而不是消息发送的过程。经过我们的调整，获取消息内容和发送消息的过程严格分离开来。

消除了代码中的冗余，代码也更容易理解，同时，给未来留出了可扩展性。如果将来retCode还有更多的情形，我们只要调整消息获取的部分进行调整就好了。当然，封装成函数是一个更好的选择，这样代码就变成了：

SendMsg("000", msgFromRetCode(retCode),outResult);

代码之丑（二）——长长的条件

这是一个长长的判断条件：

Java代码

if (strcmp(type, “DropGroup") == 0
    || strcmp(type, "CancelUserGroup") == 0
    || strcmp(type, "QFUserGroup") == 0
    || strcmp(type, "CancelQFUserGroup") == 0
    || strcmp(type, "QZUserGroup") == 0
    || strcmp(type, "CancelQZUserGroup") == 0
    || strcmp(type, "SQUserGroup") == 0
    || strcmp(type, "CancelSQUserGroup") == 0
    || strcmp(type, “UseGroup") == 0
    || strcmp(type, "CancelGroup") == 0)

之所以注意到它，因为最后两个条件是在最新修改里面加入的，换句话说，这不是一次写就的代码。单就这一次而言，只改了两行，这是可以接受的。但这是遗留代码，每次可能只改了一两行，通常我们会不只一次踏入这片土地。经年累月，代码成了这个样子。

为了让这段代码可以接受一些，我们不妨稍做封装：

 private boolean shouldExecute(String type) {
    return (strcmp(type, “DropGroup") == 0
    || strcmp(type, "CancelUserGroup") == 0
    || strcmp(type, "QFUserGroup") == 0
    || strcmp(type, "CancelQFUserGroup") == 0
    || strcmp(type, "QZUserGroup") == 0
    || strcmp(type, "CancelQZUserGroup") == 0
    || strcmp(type, "SQUserGroup") == 0
    || strcmp(type, "CancelSQUserGroup") == 0
    || strcmp(type, “UseGroup") == 0
    || strcmp(type, "CancelGroup") == 0);
  }

Java代码

  if (shouldExecute(type)) {
    ...
  }

 现在，虽然条件依然还是很多，但比起原来庞大的函数，至少它已经被控制在一个相对较小的函数里了。

虽然提取函数把这段代码混乱的条件分离开来，它还是可以继续改进的。比如，我们把判断的条件进一步提取：

Java代码

private boolean shouldExecute(String type) {
  String [] types= {
    "DropGroup",
    "CancelUserGroup",
    "QFUserGroup",
    "CancelQFUserGroup",
    "QZUserGroup",
    "CancelQZUserGroup",
    "SQUserGroup",
    "CancelSQUserGroup",
    "UseGroup",
    "CancelGroup"
  };
  int size = types.size;
  for (int i = 0; i < size; i++) {
    if (strcmp(type, types) == 0) {
      return true;
    }
  }
  return false;
}

这样的话，如果以后要加一个新的type，只要在数组中增加一个新的元素即可。

代码之丑（三）——不受欢迎的大心脏

Java代码

ColdRule newRule = new ColdRule(); 
newRule.SetOID(oldRule.GetOID()); 
newRule.SetRegion(oldRule.GetRegion()); 
newRule.SetRebateRuleID(oldRule.GetRebateRuleID()); 
newRule.SetBeginCycle(oldRule.GetBeginCycle() + 1); 
newRule.SetEndCycle(oldRule.GetEndCycle()); 
newRule.SetMainAcctAmount(oldRule.GetMainAcctAmount()); 
newRule.SetGiftAcctAmount(oldRule.GetGiftAcctAmoun t()); 
newRule.SetValidDays(0); 
newRule.SetGiftAcct(oldRule.GetGiftAcct()); 
rules.Add(newRule); 

就在我以为这一片代码就是完成给一个变量设值的时候，突然，在那个不起眼的角落里，这个变量得到了应用：它被加到了rules里面。什么叫峰回路转，这就是。

既然它给了我们这么有趣的体验，必然先杀后快。下面重构了这个函数：

Java代码

ColdRule CreateNewRule(ColdRule& oldRule) { 
   ColdRule newRule = new ColdRule(); 
   newRule.SetOID(oldRule.GetOID()); 
   newRule.SetRegion(oldRule.GetRegion()); 
   newRule.SetRebateRuleID(oldRule.GetRebateRuleID()); 
   newRule.SetBeginCycle(oldRule.GetBeginCycle() + 1); 
   newRule.SetEndCycle(oldRule.GetEndCycle()); 
   newRule.SetMainAcctAmount(oldRule.GetMainAcctAmount()); 
   newRule.SetGiftAcctAmount(oldRule.GetGiftAcctAmount()); 
   newRule.SetValidDays(0); 
   newRule.SetGiftAcct(oldRule.GetGiftAcct()); 
   return newRule; 
} 

Java代码

rules.Add(CreateNewRule(oldRule)); 

把这一堆设值操作提取了出来，整个函数看上去一下子就清爽了。不是因为代码变少了，而是因为代码按照它职责进行了划分：创建的归创建，加入的归加入。之前的代码之所以让我不安，多重职责是罪魁祸首。一旦把这个函数提取出来，做完这步操作，我们就不难发现这个函数应该成为CodeRule类的一部分。

代码之丑（四）——退让的缩进

这是一个让我纠结了很久的话题：缩进。
Java代码  

 for (int j = 0; j < attributes.size(); j++) {
    Attr *attr = attributes.get(j);
    if (attr == NULL ) {
      continue;
    }
    int IsCallFunc = -1;
    if(attr->status() == STATUS_NEW || attr->status() == STATUS_MODIFIED) {
      if(strcmp(attr->attrID(), "CallFunc") == 0) {
        if(0 == strcmp(attr->attrValue(), "1")) {
          IsCallFunc = 1;
        } else if(0 == strcmp(attr->attrValue(), "0")) {
          IsCallFunc = 0;
        }
      }
    } else if (attr->status() == STATUS_DELETED) {
      IsCallFunc = 0;
    }
    ...
  }

回到这段代码上，能出现多层缩进，for循环功不可没。出现这种循环，很多情况下，都是对一个集合进行处理，而循环里的内容，就是对集合里的每一个元素进行处理。这里也不例外。所以，我们先做一次提取：
Java代码  

 for (int j = 0; j < attributes.size(); j++) {
    processAttr(attributes.get(j));
  }
  void processAttr(Attr *attr) {
    if (attr == NULL ) {
      return;
    }
    int IsCallFunc = -1;
    if(attr->status() == STATUS_NEW || attr->status() == STATUS_MODIFIED) {
      if(strcmp(attr->attrID(), "CallFunc") == 0) {
        if(0 == strcmp(attr->attrValue(), "1")) {
          IsCallFunc = 1;
        } else if(0 == strcmp(attr->attrValue(), "0")) {
          IsCallFunc = 0;
        }
      }
    } else if (attr->status() == STATUS_DELETED) {
      IsCallFunc = 0;
    }
    ...
  }

至此，我们去掉了一层缩进，而且因为这个提取，语义也变得很清晰：这个新函数只是处理集合里的一个元素。

接下来，这个函数里面长长的代码是对IsCallFunc进行设值，后面省略的部分会根据这里求出的结果进行处理。所以，这里把processAttr进一步分拆：
Java代码  

void processAttr(Attr *attr) {
  if (attr == NULL ) {
    return;
  }
  int IsCallFunc = isCallFunc(attr);
  ......
}


int isCallFunc(Attr *attr) {
  if(attr->status() == STATUS_NEW
  || attr->status() == STATUS_MODIFIED) {
    if(strcmp(attr->attrID(), "CallFunc") == 0) {
      if(0 == strcmp(attr->attrValue(), "1")) {
          return 1;
      } else if(0 == strcmp(attr->attrValue(), "0")) {
          return 0;
      }
    }
  } else if (attr->status() == STATUS_DELETED) {
    return 0;
  }
  return -1;
}

代码之丑（五）--无状态方法

诸位Java程序员，想必大家对SimpleDateFormat并不陌生。不过，你是否知道，SimpleDateFormat不是线程安全的（thread safe）。这意味着，下面的代码是错误的：
Java代码  

class Sample {
  private static final DateFormat format = new SimpleDateFormat("yyyy.MM.dd");

  public String getCurrentDateText() {
    return format.format(new Date());
  }
}

从功能的角度上看，单独执行这段代码是没有问题的，但放到多线程环境下，因为SimpleDateFormat不是线程安全的，这段代码就会出错。所以，要想让这段代码正确，我们只要稍做微调：

Java代码  

public class Sample {
    public String getCurrentDateText() {
        return new SimpleDateFormat("yyyy.MM.dd").format(new Date());
    }
}

不知你是否注意到，这里的调整只是由原来的共享format这个变量，变成了每次调用这个方法时创建出一个新的SimpleDateFormat变量。

作为一个专业程序员，我们当然知道，相比于共享一个变量的开销要比每次创建小。之所以我们必须这么做，是因为SimpleDateFormat不是线程安全的。但从SimpleDateFormat提供给我们的接口上来看，实在让人看不出它与线程安全有和相干。那接下来，我们就要打开JDK的源码，看一下其中的代码之丑。

如果你手头没有JDK的源码，这里是个不错的参考。

在format方法里，有这样一段代码：

calendar.setTime(date);

其中，calendar是DateFormat的protected字段。这条语句改变了calendar，稍后，calendar还会用到（在subFormat方法里），而这就是引发问题的根源。

想象一下，在一个多线程环境下，有两个线程持有了同一个SimpleDateFormat的实例，分别调用format方法：

线程1调用format方法，改变了calendar这个字段。
中断来了。
线程2开始执行，它也改变了calendar。
又中断了。
线程1回来了，此时，calendar已然不是它所设的值，而是走上了线程2设计的道路。
BANG！！！ 稍微花点时间分析一下format的实现，我们便不难发现，用到calendar，唯一的好处，就是在调用subFormat时，少了一个参数，却带来了这许多的问题。其实，只要在这里用一个局部变量，一路传递下去，所有问题都将迎刃而解。
这个问题背后隐藏着一个更为重要的问题：无状态。

无状态方法的好处之一，就是它在各种环境下，都可以安全的调用。衡量一个方法是否是有状态的，就看它是否改动了其它的东西，比如全局变量，比如实例的字段。format方法在运行过程中改动了SimpleDateFormat的calendar字段，所以，它是有状态的。

写程序，我们要尽量编写无状态方法。