重新组织代码

码农天地 - 2020-12-17 22:16:07

代码应当易于理解代码的写法应当使他人理解它所需的时间最小化把信息装进名字中清晰和精确比装可爱好;使用专业的词;使用具体的名字来更细致地描述事物;给变量名带上重要的细节;为作用域大的名字采用更长的名字;有目的地使用大小写，下划线等;要多问自己几遍：“这个名字会被别人解读成其他的含义吗？” 要仔细审视这个名字，不会被误解的名字是最好的名字;命名极限最清楚的方式是在要限制的东西前加上max_或者min_;为布尔值命名时，避免使用反义的词（例如disable_ssl）;要小心用户对特定词的期望。例如，用户会期望get()或者size()是轻量的方法;审美一致的风格比“正确”的风格更重要;如果多个代码块做相似的事情，尝试让他们有同样的剪影;把代码按“列”对齐可以让代码更容易浏览;如果在一段代码中提到A,B,C，那么不要在另一段中说B,C,A，选择一个有意义的次序，并始终用这样的顺序;用空行来把大块代码分成逻辑上的“段落”;注释注释的目的是尽量帮助读者了解的和作者一样多;

什么地方不需要注释:

能从代码本身中迅速地推断的事实;用来粉饰烂代码的“拐杖式注释”--应该把代码改好;

你应当记录下来的想法包括:

对于为什么代码写成这样而不是那样的内在理由（“指导性批注”）;代码中的缺陷，使用像TODO:或者XXX:这样的标记;常量背后的故事，为什么是这个值;

站在读者的立场上思考:

预料到代码中哪些部分会让读者说：“啊？” 并且给他们加上注释;为普通读者意料之外的行为加上注释;在文件/类的级别上使用“全局观”注释来解释所有的部分是如何一起工作的;用注释来总结代码块，使读者不至于迷失在细节中;注释应当有很高的信息/空间率;尽量精确地描述函数的行为;在注释中用精心挑选的输入/输出例子进行说明;声明代码的高层次意图，而非明显的细节;用含义丰富的词来使注释简洁;控制流把条件，循环以及其他对控制流的改变做的越“自然”越好，运用一种方式使读者不用停下来重读你的代码;相对于追求最小化代码行数，一个更好的度量方法是最小化人们理解它所需的时间;当你对代码做改动时，从全新的角度审视它，把它作为一个整体来看待;在写一个比较时，把改变的值写在左边并且把更稳定的值写在右边更好一些;你也可以重新排列if/else语句中的语句块，通常来讲，先处理正确的/简单的/有趣的情况;尽量不要用三目运算符;嵌套的代码块需要更加集中精力去理解，应该把它们改写成更加“线性”的代码来避免深浅套;通常来讲提早返回可以减少嵌套并让代码整洁;表达式把你的超长表达式拆分成更容易理解的小块;要小心“智能”的小代码块--它们往往在以后会让别人读起来感到困惑;

引入“解释变量”来代表较长的子表达式，这种方式有三个好处:

它把巨大的表达式拆成小段;它通过用简单的名字描述子表达式来让代码文档化;它帮助读者识别代码中的主要概念;用德摩根定理来操作逻辑表达式--可以把布尔表达式用更整洁的方式重写（例如if(!(a&&!b))变成if(!a||b)）;有时需要把问题“反向”或者考虑目标的对立面;变量与可读性你希望你的同事随时都觉得是在面试吗;让你的变量对尽量少的代码行可见;操作一个变量的地方越多，越难以确定它的当前值;减少变量，即那些妨碍的变量;减小变量的作用域，越小越好，把变量移到一个有最少代码可以看到它的地方，眼不见，心不烦;只写一次的变量更好，那些只设置一次值的变量（或者const, final, 常量）使得代码更容易理解;重新组织代码把一般代码和项目专有的代码分开;应该把代码组织得一次只做一件事情;把想法变成代码，用自然语言描述解决方案;最好的代码就是没有代码;删除没用的代码;从项目中消除不必要的功能，不要过度设计;重新考虑需求，解决版本最简单的问题，只要能完成工作就行;经常性地通读标准库的整个API，保持对他们的熟悉程度 -- “不要重复造轮子”;测试测试也应当具有可读性，以便其他程序员可以舒服地改变或者增加测试;对使用者隐去不重要的细节，以便更重要的细节会更突出;让错误消息具有可读性;又简单又能完成工作的测试值更好;每个测试的最高一层应该越简明越好，最好每个测试的输入/输出可以用一行代码来描述;如果测试失败了，它所发出的错误消息应该能让你容易跟踪并修正这个bug;使用最简单的并且能够完整运用代码的测试输入;给测试函数取一个有完整描述性的名字，以使每个测试所测到的东西很明确，不要使用test1()，而要使用test_<functionName>这样的名字;最重要的是，要使它易于改动和增加新的测试;

特别申明：本文内容来源网络，版权归原作者所有，如有侵权请立即与我们联系（cy198701067573@163.com），我们将及时处理。