Best practise ——什么样的代码更应该精雕细琢

代码的价值不在本身大小和复杂度，而在于多少其他代码在用它。

我们的一个产品依然有很多代码采用了“点连接的长行代码”，比如权限检查代码：

// 检查当前用户是否有对象搜索的权限

AppUtils.UserInfo.CheckLimit(CarpaServer.Common.OperatorLimit.LIMIT_OBJECT_HISTORY_SEARCH) ;

这样的代码，尽管只有一行，但是冗余非常的多——每次都要重复的加入

AppUtils.UserInfo命名空间，CarpaServer.Common。如果不这样，就会需要using ；也是很麻烦的。

单独看这样的一行代码，很多人的反应是：这么点的差别何必改它呢？虽然不爽，但是也不是多大的问题。可是放眼整个项目，可以想得见，类似的代码必然大量出现。冗余因此会被放大很多倍数。

我查询了下这个产品的代码，在编码过程中（没有完成项目代码的时候）发现有990次使用。引用如此众多，优化也就是必要的了。

实现一个属性

Public  static  Limit.OBJECT_HISTORY_SEARCH

{

get{

return AppUtils.UserInfo.CheckLimit(CarpaServer.Common.OperatorLimit.LIMIT_OBJECT_HISTORY_SEARCH) ;

}

}

其他使用的地方只要这样调用就行了：

Limit.OBJECT_HISTORY_SEARCH

不仅仅权限，还有配置类，也是到处都在用的代码，比如:

代码类型：配置,包括 SysData，SysData1，UserConfig

方法：AppUtils.CheckUserConfig("userconfig", "btypeall", "1") == "0"

新方法： public bool UserConfig.BtypeAll

在配置类代码内，好处不仅仅是简洁，还有后者没有字符串的出现，都是强类型的代码，也不必使用和字符串比较这么低级的操作，用户使用起来就更舒服。

配置代码，权限代码的特点是到处都在使用，一旦写就，以后也就不好修改了——这也是分销一直没有动它的原因。因此，这样的简单封装，一定要一开始就做对。幸运的是，这样的事情一次做对并不困难。

代码质量不仅仅影响阅读效果，还会影响心情，对做编码的程序员来说，心情成本是非常值得重视的。