读书笔记2-《代码大全2》

软工读书笔记2-《代码大全2》

继上周阅读《人月神话》后对软工这门学科有了比较全面的认识，以及相关的一些管理规则等等，本周我打算开始看一些关于编程规则与技巧的书籍，于是我选择了这本《代码大全2》。

这本书讲的是如何编写出高质量的代码，这是作者在序言中就明确说明的。这本书内容繁多，我打算先按作者给出的建议进行部分章节的阅读。

首先，作为低年级学生，我先阅读了第11章“变量名的力量”。本章节可以说是全书一大亮点，因为大多数教科书都会简略带过，无非是老生常谈怎么选择缩写什么的。读过以后确有感触，这是一个重要的细节，自身在这方面也还有不小缺陷。

1.取变量名最重要的一点就是要能完全、准确地描述出该变量所代表的事物，不能让人误解、混淆，这不仅方便别人阅读你的代码，自己检查起来也会方便很多。2.变量名的长度也要适中，太短则涵盖不了所有信息，太长则会严重影响代码的可读性，一般认为变量名长度在10~16个字符之间最优，当包含信息过多时我们可以选择缩写。3.变量名的长度一般与其作用域成正相关，这是经常被忽视的潜规则，最常见的就是for循环里的控制变量，我们一般习惯用i.j.k，他们只在循环里起作用，这让我想到自己写c的时候经常用一个字母做贯穿整个main的状态变量，而在for或者是while里面用column、line这样的下表变量。4.有的时候我们的定性思维也会造就不好的编程习惯，比如说一要用状态指示变量我们立马想到flag，一要用临时变量我们就想到temp，这些确实是不错的变量，但是在一些复杂的代码中，这样的变量可读性太差，当然你肯定知道他们是标志、是临时变量，但具体什么含义，一时半会可就弄不清楚了。5.关于缩写，所有编程者一定都深有体会，好的缩写能极大地简化代码，增强可读性，一些不恰当的缩写则可能把好的代码弄得一团糟，比如说currentDate就没必要缩写成cd，因为这样的变量会让读者困惑，很难想到它的含义。此外还想举个不太恰当的例子，相比现在大家都在忙着自学VS、opencv、AS、html等等，当然他们已经实现了在IT领域的普及，现在看这些缩写反倒觉得挺好，但如果说把他们当作代码中的变量，我觉得opencv是最好的，想必大部分人需要去查VS 是什么的缩写才能知道它的含义，而opencv不同，open自然不用说，cv让人很自然地想到computer vision（当然有之前听说opencv与视图有关以及经常遇见cv缩写的因素），上述只是举例总结一下，不代表任何其他观点。最后用一句话总结，变量名的选取规则是为了阅读方便而不是编写方便。

其次，我采用了一下作者对自学编程者的建议，阅读了第七章“高质量的子程序”，对其中关于子程序最佳长度的讨论尤有感触。

我们在编程时都避不开子程序，子程序是为了避免代码重复、实现代码的模块化等等，可以为编程带来极大的便利，因此我们必须熟练掌握编写子程序的规则和技巧。子程序的名字和变量名一样，也有相应的讲究，重点更在于子程序本身的长度。

一般情况下我们写子程序时都会自觉遵从单一性原则，也就是说一个子程序就做一件事，比如说学数据结构时，我们写哈希表时会单独用一个子程序来计算哈希地址，这也是为了使代码结构更清晰、可读性更高、出错率更低，这样的话我们通常都不会写出太长的子程序，但有的时候为了适应复杂功能的需要，我们不得不写出100~200行这样规模的子程序，研究表明，子程序的长度并不是影响代码可读性与错误率的首要因素，与其一味地主观限制其长度，不如考虑更深层次的因素——子程序的内聚性、嵌套的层次、变量的数目、注释等等，但值得我们注意的是，太长的子程序（一般认为在200行以上）对程序可读性的 影响是无法避免的。

最后再提及一点书中详述的部分，就是关于子程序的参数问题。在数据结构编程的树型结构部分，我印象十分深刻，当时是用一个子程序来计算树的深度，使用的是递归（当然这是很危险的，只是在树这样特殊的结构中使用起来很方便），调试很久发现不了问题，后来反应过来，我没把记录当前深度的变量代入子程序的函参列表，导致从头到尾只加了一次，现在想起来听可笑的。但也着实对参数这个问题有了更深入的认识，参数是主程序与子程序的接口，所以应特加小心，包括一些是否引用的问题，曾经都是我编程的拦路虎，这本书中的内容对我还是很有借鉴意义的，在此不再详述了。

《代码大全2》介绍了很多高效编程的方法，对编程者是大有裨益的。虽然很基础，但也是最重要的。软工是一门考验编程的学科，注意好了各个细节，完备了各项技能，才能开发出好的软件。