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

 

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

 

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

 

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

 

 

评论

4 楼 1000copy 2010-06-11  

fansfirst2008 写道

背后的设计原则和一步一步的重构趋向模式

我正是我的愿望,thx

3 楼 fansfirst2008 2010-06-11  

我就很喜欢楼主的博客!让我体会到细节决定成败的道理!
就象一步到位的设计模式一样,只多是好看
而我觉得真正的美妙之处在于:背后的设计原则和一步一步的重构趋向模式
而楼主正是如此做到的

2 楼 1000copy 2010-06-10  

to javeeyevip ：
show ,don't just tell.
（原谅我用英文回复，因为它比较贴切）

1 楼 javaeyevip 2010-06-10  

分享精神值得赞赏，但这样检查权限的方法就显得太低级了。