| 热门文章 |
 |
|
| 编辑推荐 |
|
|
|
|
|
|
作者：中译者：叶秉哲
来源：永远的UNIX 点击： 更新：2006-12-19
|
|
＝＝ Ｐａｒｔ ３／４ ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ =============================
■□ 第１４节：程式风格指导
=============================
Q81：有任何好的 C++ 程式写作的标准吗？
感谢您阅读这份文件，而不是再发明自己的一套。
但是请不要在 comp.lang.c++ 里问这问题。几乎所有软体工程师，或多或少都把这
种东西看成是「大玩具」。而且，一些想成为 C++ 程式撰写标准的东西，是由那些
不熟悉这语言及方法论的人弄出来的，所以最後它只能成为「过去式」的标准。这种
「摆错位置」的现象，让大家对程式写作标准产生不信任感。
很明显的，在 comp.lang.c++ 问这问题的人，是想使自己更精进，不会因自己的无
知而绊倒，然而一些回答却只是让情况更糟而已。
========================================
Q82：程式撰写标准是必要的吗？有它就够了吗？
程式撰写标准不会让不懂 OO 的人变懂；只有训练及经验才有可能。如果它有用处的
话，那就是抑制住那些琐碎无关紧要的程式片段－－当大机构想把零散的程式设计组
织整合起来时，这些片段常常会出现。
但事实上你要的不光是这种标准而已。它们提供的架构让新手少去担心一些自由度，
但是系统化的方法论会比这些好看的标准做得更好。组织机构需要的是一致性的设计
与实行“哲学”，譬如：强型别或弱型别？用指标还是参考介面？ stream I/O 还是
stdio？ C++ 程式该不该呼叫 C 的？反过来呢？ ABC 该怎麽用？继承该用为实作的
技巧还是特异化的技巧？该用哪一种测试策略？一一去检查吗？该不该为每个资料成
员都提供一致的 "get" 和 "set" 介面？介面该由外往内还是由内往外设计？错误状
况该用 try/catch/throw 还是传回值来处理？……等等。
我们需要的是详细的“设计”部份的「半标准」。我推荐一个三段式标准：训练、谘
询顾问以及程式库。训练乃提供「密集教学」，谘询顾问让 OO 观念深刻化，而非仅
仅是被教过而已，高品质的程式库则是提供「长程的教学」。上述三种培训都有很热
门的市场景况。（【译注】无疑的，这是指美、加地区。）接受过上述培训的组织都
有如此的忠告：「买现成的吧，不要自己硬干 (Buy, Don't Build.)。」买程式库，
买训练课程，买开发工具，买谘询顾问。想靠自学来达到成功的工具厂商及应用／系
统厂商，都会发现成功很困难。
【译注】这一段十分具有参考价值。不过有些背景资料得提供给各位参考。别忘了：
作者是美国人，是以该地为背景，且留意一下他所服务的公司是做什麽的..
... :-) 唉！国内有这麽多的专业顾问公司吗？ :-<
少数人会说：程式撰写标准只是「理想」而已，但在上述的组织机构中，它仍有其必
要性。
底下的 FAQs 提供一些基本的指导惯例及风格。
========================================
Q83：我们的组织该以以往 C 的经验来决定程式撰写标准吗？
No!
不论你的 C 经验有多丰富，不论你有多高深的 C 能力，好的 C 程式员并不会让你
直接就成为好的 C++ 程式员。从 C 移到 C++ 并不仅是学习 "++" 的语法语意而已
，一个组织想达到 OOP 的境界，却未将 "OO" 的精神放进 OOP 里的话，只是自欺罢
了；会计的资产负债表会把他们的愚蠢显现出来。
C++ 程式撰写标准应该由 C++ 专家来调整，不妨先在 comp.lang.c++ 里头问问题（
但是不要用 "coding standard" 这种字眼；只要这样子问：「这种技巧有何优缺点
？」）。找个能帮你避开陷阱的高手，上个训练课程，买程式库，看看「好的」程式
库是否合乎你的程式撰写标准。绝对不要光靠自己来制定标准，除非你对它已有某种
程度的掌握。没有标准总比有烂标准好，因为不恰当的「官方说法」会让不够聪明的
平民难以追随。现在 C++ 训练课程及程式库，已有十分兴盛的市场。
再提一件事：当某个东西炙手可热时，招摇撞骗者亦随之而生；务必三思而後行。也
要问一下从某处修过课的人，因为老手不见得也是个好教员。最後，选个懂得指导别
人的从业人员，而不是个对此语言／方法论只有过时知识的全职教师。
【译注】善哉斯言！
========================================
Q84：我该在函数中间或是开头来宣告区域变数？
在第一次用到它的地方附近。
物件在宣告的时候就会被初始化（被建构）。如果在初始化物件的地方没有足够的资
讯，直到函数中间才有的话，你可以在开头处初始个「空值」给它，等以後再「设定
」其值；你也可以在函数中间再初始个正确的东西给它。以执行效率来说，一开始就
让它有正确的值，会比先建立它，搞一搞它，之後再重建它来得好。以像 "String"
这种简单的例子来看，会有 350% 的速度差距。在你的系统上可能会不同；当然整个
系统可能不会降低到 300+%，但是“一定”会有不必要的性能衰退现象。
常见的反驳是：「我们会替物件的每个资料提供 "set" 运作行为，则建构时的额外
耗费就会分散开来。」这比效能负荷更糟，因为你添加了维护的梦靥。替每个资料提
供 "set" 运作行为就等於对资料不设防：你把内部实作技巧都显露出来了。你隐藏
到的只有成员物件的实体“名字”而已，但你用到的 List、String 和 float（举例
来说）型态都曝光了。通常维护会比 CPU 执行时间耗费的资源更多。
区域变数应该在靠近它第一次用到之处宣告。很抱歉，这和 C 老手的习惯不同，但
是「新的」不见得就是「不好的」。
========================================
Q85：哪一种原始档命名惯例最好？ "foo.C"? "foo.cc"? "foo.cpp"?
如果你已有个惯例，就用它吧。如果没有，看看你的编译器，看它用的是哪一种。典
型的答案是：".C", ".cc", ".cpp", 或 ".cxx"（很自然的，".C" 副档名是假设该
档案系统会区分出 ".C" ".c" 大小写）。
在 Paradigm Shift 公司，我们在 Makefiles 里用 ".C"，即使是在不区分大小写的
档案系统下（在有区分的系统中，我们用一个编译器选项：「假设 .c 档案都是 C++
的程式」；譬如：IBM CSet++ 用 "-Tdp"，Zortech C++ 用 "-cpp"，Borland C++用
"-P"，等等）。
========================================
Q86：哪一种标头档命名惯例最好？ "foo.H"? "foo.hh"? "foo.hpp"?
如果你已有个惯例，就用它吧。如果没有，而且你的编辑器不必去区分 C 和 C++ 档
案的话，只要用 ".h" 就行了，否则就用编辑器所要的，像 ".H"、".hh" 或是
".hpp"。
在 Paradigm Shift 公司，我们用 ".h" 做为 C 和 C++ 的原始档案（然後，我们就
不再建那些纯粹的 C 标头档案）。
========================================
Q87：C++ 有没有像 lint 那样的指导原则？
Yes，有一些常见的例子是危险的。
但是它们都不尽然是「坏的」，因为有些情况下，再差的例子也得用上去。
* "Fred" 类别的设定运算子应该传回 "*this"，当成是 "Fred&"（以允许成串的设
定指令）。
* 有任何虚拟函数的类别，都该有个虚拟解构子。
* 若一个类别有 {解构子，设定运算子，拷贝建构子} 其一的话，通常三者也都全
部需要。
* "Fred" 类别的拷贝建构子和设定运算子，都该将它们的参数加上 "const"：分别
是 "Fred::Fred(const Fred&)" 和 "Fred& Fred::operator=(const Fred&)" 。
* 类别的子物件一定要用初始化串列 (initialization lists) 而不要用设定的方
式，因为对使用者自订类别而言，会有很大的效率差距（3x!）。
* 许多设定运算子都应该先测试：「我们」是不是「他们」；譬如：
Fred& Fred::operator= (const Fred& fred)
{
if (this == &fred) return *this;
//...normal assignment duties...
return *this;
}
有时候没必要测试，但一般说来，这些情况都是：没有必要由使用者提供外显的
设定运算子的时候（相对於编译器提供的设定运算子）。
* 在那些同时定义了 "+="、"+" 及 "=" 的类别中，"a+=b" 和 "a=a+b" 通常应该
做同样的事；其他类似的内建运算子亦同（譬如：a+=1 和 ++a; p[i] 和 *(p+i);
等等）。这可使用二元运算子 "op=" 之型式来强制做到；譬如：
Fred operator+ (const Fred& a, const Fred& b)
{
Fred ans = a;
ans += b;
return ans;
}
这样一来，有「建构性」的二元运算甚至可以不是夥伴。但常用的运算子有时可
能会更有效率地实作出来（譬如，如果 "Fred" 类别本来就是个 "String"，且
"+=" 必须重新配置／拷贝字串记忆体的话，一开始就知道它的最後长度，可能会
比较好）。
==============================================
■□ 第１５节：Smalltalk 程式者学习 C++ 之钥
==============================================
Q88：为什麽 C++ 的 FAQ 有一节讨论 Smalltalk？这是用来攻击 Smalltalk 的吗？
世界上「主要的」两个 OOPLs 是 C++ 与 Smalltalk。由於这个流行的 OOPL 已有第
二大的使用者总数量，许多新的 C++ 程式者是由 Smalltalk 背景跳过来的。这一节
会回答以下问题：
* 这两个语言的差别？
* 从 Smalltalk 跳到 C++ 的程式者，要知道些什麽，才能精通 C++？
这一节 *!*不会*!* 回答这些问题：
* 哪一种语言「最好」？
* 为什麽 Smalltalk「很烂」？
* 为什麽 C++「很烂」？
这可不是对 Smalltalk 恐怖份子挑□，让他们趁我熟睡时戳我的轮胎（在我很难得
有空休息的这段时间内 :-) 。
========================================
Q89：C++ 和 Smalltalk 的差别在哪？
最重要的不同是：
* 静态型别或动态型别？
* 继承只能用於产生子型别上？
* 数值语意还是参考语意 (value vs reference semantics)？
头两个差异会在这一节中解释，第三点则是下一节的讨论主题。
如果你是 Smalltalk 程式者，现在想学 C++，底下三则 FAQs 最好仔细研读。
========================================
Q90：什麽是「静态型别」？它和 Smalltalk 有多相似／不像？
静态型别（static typing）是说：编译器会“静态地”（於编译时期）检验各运算
的型态安全性，而不是产生执行时才会去检查的程式码。例如，在静态型别之下，会
去侦测比对函数引数的型态签名，不正确的配对会被编译器挑出错误来，而非在执行
时才被挑出。
OO 的程式里，最常见的「型态不符」错误是：欲对某物件启动个成员函数，但该物
件并未准备好要处理该运算动作。譬如，如果 "Fred" 类别有成员函数 "f()" 但没
有 "g()"，且 "fred" 是 "Fred" 类别的案例，那麽 "fred.f()" 就是合法的，
"fred.g()" 则是非法的。C++（静态地）在编译期捕捉型别错误，Smalltalk 则（动
态地）在执行期捕捉。（技术上，C++ 很像 Pascal－－“半”静态型别－－因为指
标转型与 union 都能用来破坏型别系统；这提醒了我们：你用指标转型与 union 的
频率，只能像你用 "goto" 那样。）
========================================
Q91：「静态型别」与「动态型别」哪一种比较适合 C++？
若你想最有效率使用 C++，请把她当成静态型别语言来用。
C++ 极富弹性，你可以（藉由指标转型、union 或 #define）让她「长得」像
Smalltalk。但是不要这样做。这提醒了我们：少用 #define。
有些场合，指标转型和 union 是必要的，甚至是很好的做法，但须谨慎为之。指标
转型等於是叫编译器完全信赖你。错误的指标转型可能会毁坏堆积、在别的物件记忆
体中乱搞、呼叫不存在的运作行为、造成一般性错误（general failure）。这是很
糟糕的事。如果你避免用与这些相关的东西，你的 C++ 程式会更安全、更快，因为
能在编译期就检测的东西，就不必留到执行期再做。
就算你喜欢动态型别，也请避免在 C++ 里使用，或者请考虑换另一个将型态检查延
迟到执行期才做的语言。C++ 将型态检验 100% 都放在编译时期；她没有任何执行期
型态检验的内建机制。如果你把 C++ 当成一个动态型别的 OOPL 来用，你的命运将
操之汝手。
========================================
Q92：怎样分辨某个 C++ 物件程式库是否属於动态型别的？
提示 #1：当所有东西都衍生自单一的根类别（root class），通常叫做 "Object"。
提示 #2：当容器类别 container classes，像 List、Stack、Set 等，都不是
template 版的。
提示 #3：当容器类别（List、Stack、Set 等）把插入／取出的元素，都视为指向
"Object" 的指标时。（你可以把 Apple 放进容器中，但当你取出时，编
译器只知道它是衍生自 Object，所以你得用指标转型将它转回 Apple* ；
你最好祈祷它真的是个 Apple，否则你会脑充血的。）
你可用 "dynamic_cast"（於 1994 年才加入的）来使指标转型「安全些」，但这种
动态测试依旧是“动态”的。这种程式风格是 C++ 动态型别的基本要素，你可以呼
叫函数：「把这个 Object 转换成 Apple，或是给我个 NULL，如果它不是 Apple的
话」，你就得到动态型别了：直到执行时期才知道会发生什麽事。
若你用 template 去实作出容器类别，C++ 编译器会静态侦测出 99% 的型态资讯（
"99%" 并不是真的；有些人宣称能做到 100%，而那些需要持续性 (persistence) 的
人，只能得到低於 100% 的静态型别检验）。重点是：C++ 透过 template 来做到泛
型（genericity），而非透过继承。
========================================
Q93：在 C++ 里怎样用继承？它和 Smalltalk 有何不同？
有些人认为继承是用来重用程式码的。在 C++ 中，这是不对的。说明白点，「继承
不是『为』重用程式码而设计的。」
【译注】这一个分野相当重要。否则，C++ 使用者就会感染「继承发烧症」
(inheritance fever)。
C++ 继承的目的是用来表现介面一致性（产生子类别），而不是重用程式码。C++ 中
，重用程式码通常是靠「成份」(composition) 而非继承。换句话说，继承主要是用
来当作「特异化」(specialization) 的技术，而非实作上的技巧。
这是与 Smalltalk 主要的不同之处，在 Smalltalk 里只有一种继承的型式（C++ 有
"private" 继承－－「共享程式码，但不承袭其介面」，有 "public" 继承－－表现
"kind-of" 关系）。Smalltalk 语言非常（相对於只是程式的习惯）允许你置放一个
override 覆盖（它会去呼叫个「我看不懂」的运作行为），以达到「隐藏住」继承
下来的运作行为的“效果”。更进一步，Smalltalk 可让观念界的 "is-a" 关系“独
立於”子类别阶层之外（子型别不必也是子类别；譬如，你可以让某个东西是一个
Stack，却不必继承自 Stack 类别）。
相反的，C++ 对继承的限制更严：没办法不用到继承就做出“观念上的 is-a”关系
（有个 C++ 的解决方法：透过 ABC 来分离介面与实作）。C++ 编译器利用公共继承
额外附的语意资讯，以提供静态型别。
========================================
Q94：Smalltalk/C++ 不同的继承，在现实里导致的结果是什麽？
Smalltalk 让你做出不是子类别的子型别，做出不是子型别的子类别，它可让
Smalltalk 程式者不必操心该把哪种资料（位元、表现型式、资料结构）放进类别里
面（譬如，你可能会把连结串列放到堆叠类别里）。毕竟，如果有人想要个以阵列做
出的堆叠，他不必真的从堆叠继承过来；喜欢的话，他可以从阵列类别 Array 中继
承过来，即使 ArrayBasedStack 并“不是”一种阵列！）
在 C++ 中，你不可能不为此操心。只有机制（运作行为的程式码），而非表现法（
资料位元）可在子类别中被覆盖掉，所以，通常你“不要”把资料结构放进类别里比
较好。这会促成 Abstract Base Classes (ABCs) 的强烈使用需求。
我喜欢用 ATV 和 Maseratti 之间的差别来比喻。ATV（all terrain vehicle，越野
车）很好玩，因为你可以「到处逛」，任意开到田野、小溪、人行道等地。另一方面
，Maseratti 让你能高速行驶，但你只能在公路上面开。就算你喜欢「自由表现力」
，偏偏喜欢驶向丛林，但也请不要在 C++ 里这麽做；它不适合。
========================================
Q95：学过「纯种」的 OOPL 之後才能学 C++ 吗？
不是（事实上，这样可能反而会害了你）。
（注意：Smalltalk 是个「纯种」的 OOPL，而 C++ 是个「混血」的 OOPL。）读这
之前，请先读读前面关於 C++ 与 Smalltalk 差别的 FAQs。
OOPL 的「纯粹性」，并不会让转移到 C++ 更容易些。事实上，典型的动态系结与非
子型别的继承，会让 Smalltalk 程式者更难学会 C++。Paradigm Shift 公司曾教过
数千人 OO 技术，我们注意到：有 Smalltalk 背景的人来学 C++，通常和那些根本
没碰过继承的人学起来差不多累。事实上，对动态型别的 OOPL（通常是，但不全都
是 Smalltalk）有高度使用经验的人，可能会“更难”学好，[1] [2] 下一页
|
|
|
评论
收藏
分享
打印
