代码大全之个人精粹版

代码大全精粹——个人整理版本目录设计编码质量优化设计设计关键点1.封装——信息隐藏类或模块，只提供合适的接口，并保持不变。实现细节和成员不要暴露给外界即其他模块。反例：

pDomain=&(g_AAADomain[DomainID]);if(READY==pDomain->Status){…}正例：if(DomainIsReady(DomainID)){…}设计关键点封转的好处：a.降低耦合。尤其是大模块之间。b.降低复杂度。修改和阅读代码时，一个时刻只用关心一层的设计，不用在庞大的代码中左支右绌。c.屏蔽变化源。例如某数据索引表从Hash表改成AVL树，不应对外部产生影响，封装可实现这种屏蔽。Notice：

封装不仅应该用在大模块上，也应该用在模块内的各子模块上。C语言中不希望被外部调用的函数，可通过函数名前加static前缀来实现信息隐藏设计关键点设计关键点2.隔离容易改变的区域找出明显容易变化的功能，将之分离出来成独立模块。设计良好接口，使变化不影响模块外部。容易变化的地方：a.业务规则。例如电话费、上网费的收费模式、费率等。b.硬件依赖性c.困难的设计区域和实现区域。因为这些设计和代码不是很好，可能需要重新做。隔离使之对系统影响最低。举例：请教练结合自己项目举例设计关键点3.抽象抽象是从众多的事物中抽取出共同的、本质性的特征，而舍弃其非本质的特征。抽象本身很“抽象”，不太容易理解。我们来通过软件实例理解：C++项目中的抽象类C项目中的通用算法库，例如Hash，就是抽象出了Hash算法的本质，而把具体的“杂凑函数”留给使用者注册。请教练结合自己项目举例设计关键点抽象的好处：关注高层规则，忽略无关细节，降低软件复杂度写出高复用性代码更好的软件层次结构Notice：

抽象与语言无关，C语言同样可实现抽象。编码子程序和变量名子程序长度

无标准。但超过200行请小心，一般只有复杂算法（如AVL树，加密等）才会写出长函数，其余情况出现长函数则要反省设计、分层是否合理。一个子程序只在自己的抽象层次上做一件事情。如果一个子程序的名字无法完全描述它做的事，就违背了这一原则。子程序和变量的名字：

总原则是让代码读起来就跟自然语言一样流畅。例如if(NameIsValid(userName)){

RemoveAllSpace(userName)…}子程序和变量名过程性子程序起强烈的“动词+宾语”的名字，例如RemoveAllSpace()等。逻辑判断子程序，名字写为肯定语句。

面向对象例子：boolCLASS_USER_NAME::IsValidName();C语言例子：BOOLNameIsValid(&userName);

使用时就是如下流畅的语句：if(userName.IsValidName())或if(!userName.IsValidName())if(NameIsValid(&userName))语句1.循环循环变量使用有意义的变量名，避免习惯性使用i,j,k反例：for(i=0;i<MAX_USER_ID;i++){for(j=0;j<MAX_PAYOUT_TYPE;i++){sum+=employee[i].payout[j];}}正例for(userID=0;userID<MAX_USER_ID;userID++){for(payType=0;payType<MAX_PAYOUT_TYPE;payType++){sum+=employee[userID].payout[payType];}}好处：提高可读性避免i,j,k写代码手误设计关键点语句2.判断语句判断语句尽量写为肯定形式，少用==判断反例：if(TRUE==procResult){….}正例：if(procSuccess){….}好处：接近自然语言，提高可读性；避免==手误为=设计关键点语句语句3.克服深层嵌套一份研究表明，很少有人能理解超过三层的嵌套。当写出深层嵌套时，如何改进？方法一：重新梳理判断逻辑，重新设计被嵌套的代码。某些情况下深层嵌套是混乱思路的产物。方法二：把深层嵌套的代码提取出来放进单独的子程序。只要提取的代码是一个完整、独立的概念。注释1.尽量写出“自说明代码”尽量让代码像自然语言一样流畅，即使不用注释也能轻松看懂。通过好的子程序名、变量名、良好逻辑分层、清晰布局、低复杂度的控制流程和数据结构等实现该目标。2.注释只允许有如下三类：1）概述性注释。说明某一段代码的总体意思。例如一个子程序中，各功能段的概述说明。2）目的性注释。说明一段代码的意图，要解决的问题，而非解决的方法。例如函数头的函数功能说明3）说明代码无法表述的信息。例如与设计有关的注意事项，优化标记等。其他类型的注释，要么是无用的，重复说明代码本身已经明白无误的内容；要么说明代码本身含糊不清，必须要另外说明，这种情况下最好改进代码。

这是理想情况。在现有代码无法达到自说明的情况下，还是要将理解有困难的地方都进行注释。注释质量优化降低程序复杂度1.什么是程序复杂度程序复杂度的一个标准：为了理解应用程序，你必须在同一时间记住的智力实体的数量直观标准：理解程序所需要花费的精力。复杂度代表什么？复杂度与程序可靠性成反比，与程序错误率成正比。复杂度高的代码可读性差，难以理解2.如何度量复杂度TomMcCabe方法：通过子程序中“决策点”来数量衡量复杂度。1.从1开始，一直往下通过程序2.一旦遇到以下关键字，或者其同类的词，就加1：if,while,repeat,for,and,or3.给case语句中的每一种情况都加1例子：如下子程序复杂度为多少？

int

firstNum(inta,intc){for(b=0;b<MAX_NUM;b++){if(a<b&&b<c){returnb;}}}降低程序复杂度4降低程序复杂度3.如何处理复杂度度量结果0-5子程序可能还不错6-10得想办法简化子程序10+把子程序的某一部分拆分成另一个子程序并调用它把子程序的一部分提取成另一个子程序，不会降低整个程序的复杂度，只是把决策点移到其他地方。但这样可以降低你在同一时间必须关注的复杂度水平。有时混乱的代码是混乱思维的产物，这种情况需要重新整理出清晰的函数逻辑。（这条是我个人的总结）10的上限不是绝对，只是一个警示。有些情况下子程序高复杂度不可避免。开发者测试1.什么是开发者测试完整测试过程：单元测试、组件测试、集成测试、回归测试、系统测试。开发者测试主要指前三项：单元测试：类或子程序测试组件测试：也就是我们的模块测试集成测试：多模块的联合测试2.推荐的测试项对每一项相关需求进行测试对每一个相关设计关注点进行测试典型数据、边界数据、错误数据测试举例：四则运算程序，请大家给出测试项。开发者测试3.推荐的测试方法测试先行保留测试用例，用于后续重新测试（回归测试）自动化测试，使测试可快速、频繁进行。例如测试用例函数中使用Assert判断结果，而非打印出来肉眼观察。开发者测试重构重构的定义：在不改变软件外部行为的前提下，对其内部结构进行改变，使之更容易理解并便于修改。问题：何处需要重构，怎么重构？1.何处需要重构，怎么重构这里只说明几种常见类型重复。代码重复、结构重复、逻辑重复。重复的代码是抽象不够的表现。如果是一个独立完整的概念，可以提取成一个子程序（抽象）。举例：多处的排序算法。冗长子程序。如果把子程序的一部分提取来作为另一个独立的子程序，可以让代码更清晰，就提取成子程序。循环过长或嵌套过深。循环内部的复杂代码往往可以转换成子程序。嵌套过深可以用前面“语句”中提过的方法解决。子程序命名不当。需要子程序重命名，或合并、拆分子程序。难懂、拙劣的代码。需要重整逻辑和流程。问题：何时进行重构？重构2.重构的时机开发时，不断重构。在开发阶段，每完成一个小功能点、或修补一个缺陷时，都应该审视是否有需要重构的地方，保证持续集成中代码不腐化。维护时，因故障或需求变化而修改某功能时，对修改到的代码进行重构。但注意只能重构修改的地方！不能在解决故障时重构与之无关的代码！问题：如何保证重构安全？这可能是阻碍我们进行重构的最大因素！重构3.如何保证重构安全重构前保存初始代码，保证重构失败可以返回。重构的步伐要小。尽量一次只处理一项重构，除非是最为简单的重构。重新测试（回归测试）。开发者自测阶段请保留测试用例，最好是自动化测试用例，可以迅速重新测试，看重构后的代码能否通过之前的测试用例。重构性能优化1.性能优化误区随时随地进行优化

为微观的最终效果不足道的优化，可能浪费了大量的时间，而对整个系统全局性的重要优化视而不见。同时也为了微弱的性能提升而牺牲了正确性、可读性等其他重要的软件质量。优化=修改代码

遍历查找数据的代码，再怎么修改优化，也不可能超越Hash查找算法、AVL树查找算法——优化需要先从更高层的需求、设计做起！2.什么是真正的优化按如下的优先顺序来思考提高性能：需求设计程序同操作系统交互代码编译硬件代码调整首先从需求、设计、编译器优化等级、硬件等上面提高效率，可以更全局、简单、安全、高效地提高效率。最后才是考虑代码