代码的价值不在本身大小和复杂度，而在于多少其他代码在用它。
我们的一个产品依然有很多代码采用了“点连接的长行代码”，比如权限检查代码：
// 检查当前用户是否有对象搜索的权限
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
在配置类代码内，好处不仅仅是简洁，还有后者没有字符串的出现，都是强类型的代码，也不必使用和字符串比较这么低级的操作，用户使用起来就更舒服。
配置代码，权限代码的特点是到处都在使用，一旦写就，以后也就不好修改了——这也是分销一直没有动它的原因。因此，这样的简单封装，一定要一开始就做对。幸运的是，这样的事情一次做对并不困难。
代码质量不仅仅影响阅读效果，还会影响心情，对做编码的程序员来说，心情成本是非常值得重视的。
