关于Hard Code的思考 - 程序员的管理不能简单使用制度

http://blog.csdn.net/decision/archive/2005/11/23/536011.aspx

 

版权声明：本文可以自由转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本声明

先说Hard Code吧，这个问题我想有经验的程序员都知道，但是还是说一下吧。比如有这么一段代码：

int sum = count * price * 0.75;

这里面的0.75就是一个"Magic number"，也叫hard code。有人翻译成“硬编码”。这样是不好的，因为

1。读代码的人不会知道0.75是什么意思。

2。如果这个数字将来要变化，恨难修改。

3。如果是个字符串，说不定有spell error。

...

问题很多，我就不多说了，我们是一定不能Hard Code的。

于是，为了防止程序员写出低质量的代码，“永远不能Hard Code”这一点被写入了编程规范，并且由SQA监督，定期做Code review来查看是否有人触犯编程规范。

但是，有趣的事情发生了，看下列代码：

int sum = count * price * SEVENTY_FIVE;

String sql = SELECT + BLANK + FROM + BLANK + ASTERISK + tableName + BLANK + WHERE

    + BLANK + fieldName + EQUAL + String.valueOf(sum);

看到这样的代码，做Code Review的人是看不到Hard Code了，可是这样写出来的代码，还不如Hard Code呢。问题在哪里呢？关键是那些用来替换“magic number”的变量的取名，这些变量的取名应该具有实际的意义，如果说 sum = count * price * DISCOUNT; 这样就比较好懂，因为折扣是有Business方面的意义的，而SEVENTY_FIVE是没有Business方面的意义的，而且DISCOUNT可以变成其它的值，想80，但是SEVENTY_FIVE就不能是80。

思考一下，不仅仅是如何避免Hard Code的问题，还有就是如果把这些思想在整个团队里面能正确的执行，这是一个很好玩的话题。

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/decision/archive/2005/11/23/536011.aspx