Ｃ＋＋语言常见问题解答(3)

　　 ＝＝　Ｐａｒｔ　３／４　　＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝　=============================　

■□　第１４节：程式风格指导　

=============================　

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