代码大全阅读笔记03

这一次和上一篇笔记类似,也是对名次的解释以及理解。

不要让 ADT 依赖于储存介质
这点早就意识的到,类里面最好不要有 readfromfile , writetofile 这样的方法。但是为了方便,往往又会加上这些方法。最终的结果是,依赖文件带来的不便总是比便利要多。同理,依赖文件名也是不恰当的。可悲的是,有些错误犯一次往往不够。意识到这样做的不好是很容易的,真正杜绝它是另一件事。

在万不得已时通过 private 继承来实现“has a”的关系
private 继承的主要原因是让外层的类能够访问内层被包含类的 protected 成员。根据我自己的经验,让类有 protected 成员本身就不是一件好事。我刚学 C++ 的时候,很多类都有大量的 protected ,但现在,只剩下了 private 和 public 。虽然偶有 protected ,但是我相信,那些都是可以通过改良设计然后去掉的。我不喜欢教条,如果有教条说,不准用 protected ,我会很反感。而实现上,我的感觉会排斥 protected 的使用。

对于超过 200 行代码的子程序来说,没有哪项研究发现它更够降低成本和/或降低出错率
这是个谁都懂的道理,但是错误我自己也犯过。早几年,我为大话西游编写了一个图文混排的函数,可以在聊天或是其他屏幕文字中同时显示不同的文字,有不同的颜色,状态,效果,还可以显示动画图标。当时图一时方便,还有一些效率原因,我写了一个几百行的函数。再接下来的几年里,我为这个函数多次头痛过,出过不只三次的 bug 。直到在梦幻西游的项目里,这些模块得到全部重写才舒了一口气。长达千行的子程序我也在一些地方见过,那也是非常可怕的。并非所有程序员可以真正认识到这样做的可怕程度吧。

使用 C++ 中的 const 关键字来定义输入参数
能够正确充分的使用 const 是合格的 c++ 程序员评判标准之一。

不要把子程序的参数用做工作变量
不要因为想当然的效率因素使用输入参数做工作变量,编译器会帮你优化的。如果这样做,至少在我们公司内部的 codeview 上是要被严重警告的。

确认留在代码中的错误消息是友好的
读这段的时候想到同事给我讲的一个故事:他以前的同事因为敲出脏话被开掉了,起因是他的老板(也是一个程序员)在调试代码的时候被某个模块的出错信息骂了一通 :D

哈哈,我得了 28 分(或者是 27.5) ,而且没有被作者的陷阱框住。

隐式变量声明对于任何一种语言来说都是最具危险性的特性之一
早年,我们用 Lua 的第 4 版写脚本,结果在这个问题上吃过几次大苦头。好在 lua 在第 5 版后增加了 metatable 可以有办法避免这个问题。那就是给 _G 定义一个 __newindex 的 method 。例子在 lua 包里的 test 目录下可以找到,[External Link]pil 里也应该有提到。

Rob Pike 建议使用 0xDEADBEEF 这一常量来填充内存,因为在调试器里很容易识别它。
其实还可以用 0xBADF00D 也很有趣,可惜是 7 个字母。有个朋友用这个做网名,我还蹭过一顿饭。:D

尽可能缩短变量的存活时间
这是一个浅显但实用的道理。p248 里还提到,全局变量的存活时间最长,就凭这一点,我们也应该避免使用。使用全局变量和不使用,是关易写代码和易读代码的区别;也是“方便性”和“智力可管理性”的理念区别。这一节还有个被量化的概念,变量的跨度。把一个临时变量重复使用,在增加了存活时间的同时也增加了其跨度,所以出现了很糟糕的味道。这一点在 P255 又谈了一次。

绑定时间
一般说来,变量的绑定时间越晚,灵活性越好。这里的关于绑定时间的总结很不错。分别为:
编码时绑定 (使用 magic number)
编译时绑定 (使用命名常量)
加载时绑定 (读注册表,配置文件等)
对象实例化时绑定 (创建对象时读入)
即时 (每次操作时读入)
绑定越晚,在增加灵活性的同时,也增加了耦合度。

避免让代码具有隐含含义
这里有个例子其实我曾经也类似的干过,变量 pageCount 在非负的时候表示已打印纸张的数量,否则,-1 表示有错误发生。这在技术领域里被称为“混合耦合”是应该避免的。pageCount 客串了一个 boolean 类型。如果真的想节省一个变量的空间的话,我觉得使用 union 可能能好些。
union {
int pageCount;
struct {
unsigned int unused:31;
unsigned int pageError:1;
};
};
或许这也不是个更好的方案。

在程序生命期中尽早决定国际化/本地化策略
关于这个问题,我们吃过的苦头足够说明问题。另外,MS 倡导的 _T() 宏不一定是一个优秀的方案。如果要支持 unicode ,UTF-8 是个不错的选择,虽然不总是最好的。UTF-8 表示汉字时 50% 超出的储存空间好好考虑一下。

当然有很多都是COPY过来的,不过都加着我的思想,。

原文地址:https://www.cnblogs.com/kmxbf2292/p/11070260.html