C#代码--编写高质量C#程序.doc

1.1 ?换行的讲究 4 1.1.1 ?寻找最佳的断行位置 4 1.1.2 ?每行只写一条语句 7 1.1.3 ?分行定义变量 7 1.2 ?避免代码过于拥挤 9 1.2.1 ?使用空行分隔代码块 9 1.2.2 ?使用空格降低代码密度 13 1.3 ?如何缩进 16 1.3.1 ?嵌套或包含关系引起的缩进 18 1.3.2 ?因换行而产生的缩进 23 1.3.3 ?使用空格还是Tab键 25 1.4 ?大括号 25 1.4.1 ?大括号的位置 25 1.4.2 ?空的大括号结构 27 1.4.3 ?仅包含单个语句的结构体 31 1.5 ?保持项目文件的条理性 34 1.5.1 ?解决方案的结构呼应 34 1.5.2 ?代码文件的结构 35 1.5.3 ?使用#region标记 38 第2章 养成良好的注释习惯 39 2.1 ?何时需要注释 39 2.1.1 ?解释代码的意图 40 2.1.2 ?对局部变量的说明 40 2.1.3 ?充当代码标题 42 2.1.4 ?指出例外情况 46 2.1.5 ?开发提示 47 2.2 ?注释的格式 48 2.2.1 ?单行注释 49 2.2.2 ?多行注释 51 2.3 ?正确使用XML文档注释 52 2.3.1 ?结构与类的XML文档注释 53 2.3.2 ?属性的XML文档注释 55 2.3.3 ?方法的XML文档注释 57 2.3.4 ?构造函数的XML文档注释 59 2.3.5 ?事件的XML文档注释 60 2.3.6 ?枚举类型的XML文档注释 61 2.3.7 ?泛型的XML文档注释 62 2.3.8 ?其他标记 63 总的来说，如果多看看MSDN自身的类库参考，你会发现其实XML文档注释最终形成的就是这样的结果。MSDN本身就是一个最好的XML文档注释的范例，我们可以在实践过程中不断地进行模仿和学习。第7章如何使用函数 67 7.1????????? 为什么要使用函数 67 7.1.1? 函数与方法 67 7.1.2????? 代码复用 69 7.1.3????? 隐藏细节 71 7.2??? 函数重载 76 7.2.1????? 重载的语义 76 7.2.2????? 保持核心代码唯一 81 7.3??? 参数的设计 87 7.3.1????? 参数的命名 87 7.3.2????? 不要使用保留项 87 7.3.3????? 变长参数列表 88 7.3.4????? 何时使用ref参数和out参数 91 7.3.5????? 参数的顺序 92 7.3.6????? 重载函数的参数一致 92 7.4??? 参数检查 97 7.4.1????? 检查零值及空引用 97 7.4.2????? 检查枚举类型 99 7.4.3????? 防止数据被篡改 100 7.4.4????? 在何处检查合法性 102 7.5??? 函数出口 103 7.5.1????? 返回值的用法 103 7.5.2????? 离开函数的时机 104 假设我们写的是文章而不是程序，那么你一定觉得诸如文章应该分为若干个自然段、每段开头空两格之类的规则是理所当然的。如果段落的开头不空两格，或者干脆把整个文章写成单独的一段，仔细想来似乎也不会影响文章实质内容的表达。既然如此，我们为什么还要在形式上下功夫呢？设想一下，如果你手中的这本书既无章节也无目录，正文中的不同内容都使用同样的字体字号印刷，几百页纸从头至尾洋洋洒洒如念经般地“一气呵成”，你还有耐心看下去吗？ 这是一个人人都能理解的道理，可是当文章变成程序的时候，就不是每个人都能想得通的了。不仅仅是初学者，甚至一些熟练的开发人员，也会写出凌乱不堪的代码。许多人一定有过这样的经历：一年半载之后，自己原来写的程序就完全看不懂了。如果这段程序只是为了交作业，或者临时一用，那还可以不去追究，但如果这是一个商业软件，现在需要根据客户的要求进行修改的话，工作量可就大了——你不得不先花时间把你原来的思路看懂。 肯定会有人反驳：代码是给机器运行的，又不是给人看的，写那么好看有什么用？ 他的话只对了前半句：代码确实是给机器运行的，可是机器总共才需要看它几分钟？你花一个月编写的程序，机器顶多两三分钟就编译好了——在这两三分钟之前，这代码不都是你在看吗？开发软件编写代码不是一朝一夕的事情，更多的情况下，一个软件的开发要经历很长的时间，并且常常由多人合作完成。一个庞大的软件项目，可能会动用上千名程序员工作数年！如果把代码写得连自己都看不明白，怎么与别人交流？同一个开发团队内，一定要保持良好且一致的代码风格，才能最大化地提高开发效率。 有的初学者会问：我现在只是一个人写程序，并不需要和其他人合作，这些条条框框还有什么必要吗？ 要知道，团队协作只是一个方面。我经常遇到这类情况，一些初学