好代码、坏代码之一

好代码、坏代码之一

1．命名很重要，让代码告诉你它自己

命名到底有多重要呢？

重要到这几乎是很多软件项目成功或者失败的“罪魁祸首”，究其原因，代码不光支撑了0和1在计算机系统中运行的业务逻辑，同时也是开发者进行交流与研究的标准语言。没有意义或者有歧义的命名，就像两个等待交流的人，面对了一堆火星文无从下口，让交流变成灾难，也就导致很多问题。

同时，好的命名是自说明的，让代码告诉开发者“我是谁，我做什么，我怎么做”。当然，除了静态式的必要的注释说明之外，动态式的代码也可以包含传递信息的作用，让代码告诉你它自己，因为代码是“活的代码”。

例如，以某个缓存容器为例，泛型参数明确了容器的Key和Value的关系，其中的方法也基本明确了作为缓存容器所具有的方法：Add、Set、Clear、Refresh和IsExist，而TryGetValue是Try-Parse模式的应用体现。其中的变量container表示了容器载体；expiration表示了过期时间；config表示了容器的配置信息。

publicclassAtCache<TKey,TValue>

{

publicintCount{}

publicList<TValue>Items{}

publicintExpiration{}

publicvoidAdd(TKeykey,TValuevalue){}

publicvoidSet(TKeykey,TValuevalue,intexpiry){}

publicboolTryGetValue(TKeykey,outTValuevalue){}

publicvoidClear(){}

publicboolIsExist(TKeykey){}

protectedvoidRefresh(){}

privateReaderWriterLockSlimrwLocker=newReaderWriterLockSlim();

privateDictionary<TKey,CacheItem<TKey,TValue>>container=newDictionary<TKey,CacheItem<TKey,TValue>>();

privateintexpiration;

privateDateTimelastRefresh=DateTime.Now;

privateIAtCacheConfigurationconfig;

privateList<TValue>items;

}

总体来说，让代码告诉它自己，是好代码的体现，而一堆没有意义的代码堆积是让人无法接受和容忍的坏代码。

2．遵守编码规范

编码规范，就是编码最佳实践，是前辈在编码这件事上的积累和总结，是智慧的延续和工业的实践。在软件产业日益蓬勃的今天，软件工业在于如何更有效率地进行生产这件事儿上，有了巨大的进步和积累，编码规范正是如此。例如可以随意列出很多的规范：

· 命名规范。

· 避免行数过多的方法。

· 代码缩进。

· 异常规范。

· 设计规范。

· 注释规范。

· 文件的组织规范。

· 配置规范。

· 发布与部署规范。

· 测试规范。

· SQL规范。

在以上每个领域都有N条“法规”，以最佳实践的条款被总结出来，每个条款都渗透着很多前人的智慧。同时，编码规范的应用是有选择和场合的，不同的软件公司和产品，对编码规范都有一定的理解和取舍。

但是，没有规范的编码，一定是有问题、潜伏着坏代码的幽灵。

3．遵守命名规则

命名已经被反复强调了，遵守编码规范首当其冲就是对于命名规范的遵守，对于命名规则，通常可选择的体系主要有：

· Pascal Casing，混合使用大小写字母，每个单词的首字母必须是大写，例如FirstName。

· Camel Casing，混合使用大小写字母，第一个单词的首字母是小写，其他单词的首字母是大写，例如firstName。

· 匈牙利命名法，通过属性、类型和对象描述混合来表示，例如frmMainWindow，表示一个窗体实例的命名。

不过，对于不同的语言体系而言，一般有着不同的命名规范和体系，很多不同的语言对于命名规范的选择也有差别。以C#语言为例，最基本的命名规则包括：

· 以Pascal Casing风格定义命名空间、类及其成员、接口、方法、事件、枚举等。

· 以Camel Casing规范定义参数、私有成员。

· 避免使用匈牙利命名法。

· 以Attribute作为特性的后缀。

· 以Delegate作为委托的后缀。

· 以Exception作为异常的后缀。

当然，规范还有很多，而这种积累来自于平时对于代码的理解和运用。

本文节选自《你必须知道的.NET（第2版）》一书

图书详细信息:http://blog.csdn.net/broadview2006/article/details/6673353