08代码大全2阅读笔记

Posted 2023-06-07 qwb0614

第十一章 变量名的力量

 

 变量名应该完全、准确地表示变量指代的事物。避免x xx xxx一类无意义变量名，避免dat tmp一类泛泛的变量名。

 长度：最佳为10~16个字符，8~20个字符也可以。

 变量名与作用域：

 短变量名，如i tmp常常用作临时变量。有些人因为短变量名有风险，所以建议即使临时变量也不要用短变量名。无论如何，短变量名“暗示”了局部作用域。

 全局变量名应该用限定词避免名字冲突，如cpp中的namespace，java中的package

 计算值限定词，如min max total average应该放在最末尾。这样可以突出重点属性。

同样注意对仗词。

 

 特定变量：

循环变量：常用i j k。但假如循环很长，i j k容易混淆，或变量离开循环后还会使用，建议取有意义的名字。

 状态变量：避免flag status这样的无意义名字。

 临时变量：要警惕。尽量少用temp这样的名字。

布尔值：常用名：done error found success ok…应该给布尔值取包含真/假两种状态的名字，如success，暗示了只有success和unsuccess两种状态。可以使用is开头的布尔值名字，如isFound。不要用否定意义的布尔值，如notFound。

 枚举类型：名字中应该暗示枚举类型本身的名字，如名为Color的枚举类型内部命名应为Color_Red, Color_Green等。不过对于一些枚举类型的使用很像类的语言，可以省略，如应该命名为Color.Red, Color.Green而非Color.Color_Red, Color.Color_Green。

 常量：应该根据常量的意义而非常量的值命名。

 

 在共享开发、代码可读性很重要、需要经常或长周期维护的情况下，命名规则非常重要。

  命名规则的正式程度应该依情况而定。

 一些可供参考命名规则：

区分类与变量：

首字母大写表示类，全部小写表示变量：常用于cpp, java。缺点：差别太小；有些语言大小写不敏感，不适用于混合语言开发。

 字母全部大写表示类，全部小写表示变量。缺点：cpp java中全部大写被表示常量；不适用于混合语言开发。

用t_前缀表示类型。优点：差别清晰；方法普适。缺点：不美观。

用a前缀表示变量。缺点：需要改变所有变量名，很麻烦。

 对变量采用更明确的名字。

  这里没有一个十全十美的方法。个人出于习惯偏爱第一种与第五种的结合。

 全局变量：用g_前缀标识。 成员变量：用m_前缀标识。

疑问：很多语言中成员变量直接用.运算符调用即可，为何要特殊标识？

具名常量：用c_前缀标识。

疑问：个人以为具名常量可以用明确的名称表示，加上前缀不美观、不直接。而且通常的编译器会检查是否对具名常量进行修改，不至于产生错误操作。

 枚举类型的元素：同上。

只读变量：该问题在java这样传引用的语言中尤为严重。在一些语言中可以用const保护变量，java这样的语言中可以用const前缀标识。

 格式化命名：统一采用一种格式化命名法，如下划线分割（c）、驼峰命名法（java）。

 

 与语言相关的命名规则：（在此只记录个人常用语言）

 c：c ch指字符，i j指整数下标，n指数量，p指指针，s指字符串，宏定义、typedef名字全部大写，变量名、子程序名全部小写，用下划线分割。

 cpp：i j指整数下标，p指指针，常量、typedef、宏定义全部大写，当且仅当全部大写时用下划线分割，类、变量采用驼峰命名法，类首字母大写，变量首字母小写。

 java：java的命名风格从一开始就规定了，借鉴了一些c cpp的成功经验。i j是整数下标，常量全部大写、用下划线分割，类（与接口）、变量名同cpp、采用驼峰命名法，访问器子程序用get和set前缀。

 混合语言编程时，应该使命名风格一致，即使会违背部分语言的惯例。

 

代码大全阅读笔记01

　　又是一本经典的书《代码大全》，从豆瓣上看到了很多的好评，看了一点感觉大全确实是如其名，一路下来都是很实用的东西，有些虽然都接触到了，但是再看一遍仍旧是收益很大。首先，软件构建的核心就是管理复杂度。虽然书中有不少的篇幅来讨论变量、语句等等这些编程的基本要素，还包括代码改善和调整的策略和方法，可谓不无巨细。不过深入理解一下，这些内容都是围绕着上面这句话展开的，也就是软件构建的核心就是管理复杂度。而这一目标产生的根源就在于人脑智力同软件项目复杂程度之间的矛盾。书中常常会提到几个数字，差不多在6、7左右变化，因为这是人脑智力管理的极限，多了，就管不过来了，呵呵。所以，书中会有一些结论性的建议。比如构建可工作的类，内部成员应该控制在7(+-)2，也就是5个或者9个左右，如果都是Native Type的话，9个成员变量能管的过来，如果都是对象成员的话，5个也能保证你的头脑始终清晰。还有，比如程序中的嵌套结构，类似于If，循环啊什么的，要保持嵌套层次不能多于6层，而据实际调查，一般3层以上的嵌套就会使程序员非常的困惑和抓狂了；还有比如子程序的参数个数尽量保持在7个以下，要不然也记不住，别说7个了，没有现代IDE的帮助，我连4个以上的参数我都记不住，呵呵。

　　我想满足这些指标并不是很难的事情，而这些东西也给出了对于代码进行改善时候可以依据的标准。不过想要管理这种复杂度，从作者的书中总结一下，具体可能是以下几点：第一，分割，既然大脑管不过来，那就把系统进行分割，也就是从设计角度上抽象出若干部分，每次让大脑focus在一个部分上，这点我是有深刻体会，虽然我现在完全自己做的东西超不过15000行，不过也不能妄想自己把所有的部分都记住，如果抽象的不好的话，我就特别头疼，每天在代码中翻来翻去的，效率非常低；第二，清晰理解，其实这点跟上面一点是差不多的，只有清晰理解了抽象的含义，才能做好每个封装每个接口，这样在关注别的抽象部分的时候，其他部分需要记住和管理的更清晰也更简洁，因为不需要关注其他部分是如何实现的，只要按照接口和抽象来做就好了；第三，清晰表达，在程序中应该清晰表达逻辑和抽象含义，也就是增加程序的可读性，唉，这点太重要了，书上也围绕着这个不断的论述，上面提到那些事无巨细的部分反复的说着这一点，甚至连命名都有专门的一章来讨论。

　　这本书我并不打算一口气一遍，这可能太过于囫囵吞枣，那样可能得到的不会太多，所以，还是慢慢啃，我想笔记的作业性质不应该那么重，老师也是在催促我们学习，真正学不学当然还是看自己，反正愿意骗自己没人会知道也没人会提醒你！