==Part3/4=========================================================
■□第14节:程式风格指导
=============================
Q81:有任何好的C++程式写作的标准吗?
感谢您阅读这份文件,而不是再发明自己的一套。
但是请不要在comp.lang.c++里问这问题。几乎所有软体工程师,或多或少都把这
种东西看成是「大玩具」。而且,一些想成为C++程式撰写标准的东西,是由那些
不熟悉这语言及方法论的人弄出来的,所以最後它只能成为「过去式」的标准。这种
「摆错位置」的现象,让大家对程式写作标准产生不信任感。
很明显的,在comp.lang.c++问这问题的人,是想使自己更精进,不会因自己的无
知而绊倒,然而一些回答却只是让情况更糟而已。
========================================
Q82:程式撰写标准是必要的吗?有它就够了吗?
程式撰写标准不会让不懂OO的人变懂;只有练习及经验才有可能。假如它有用处的
话,那就是抑制住那些琐碎无关紧要的程式片段--当大机构想把零散的程式设计组
织整合起来时,这些片段经常会出现。
但事实上你要的不光是这种标准而已。它们提供的架构让新手少去担心一些自由度,
但是系统化的方法论会比这些好看的标准做得更好。组织机构需要的是一致性的设计
与实行“哲学”,譬如:强型别或弱型别?用指标还是参考介面?streamI/O还是
stdio?C++程式该不该呼叫C的?反过来呢?ABC该怎麽用?继续该用为实作的
技巧还是特异化的技巧?该用哪一种测试策略?一一去检查吗?该不该为每个资料成
员都提供一致的"get"和"set"介面?介面该由外往内还是由内往外设计?错误状
况该用try/catch/throw还是传回值来处理?……等等。
我们需要的是具体的“设计”部份的「半标准」。我推荐一个三段式标准:练习、谘
询顾问以及程式库。练习乃提供「密集教学」,谘询顾问让OO观念深刻化,而非仅
仅是被教过而已,高品质的程式库则是提供「长程的教学」。上述三种培训都有很热
门的市场景况。(【译注】无疑的,这是指美、加地区。)接受过上述培训的组织都
有如此的忠告:「买现成的吧,不要自己硬干(Buy,Don'tBuild.)。」买程式库,
买练习课程,买开发工具,买谘询顾问。想靠自学来达到成功的工具厂商及应用/系
统厂商,都会发现成功很困难。
【译注】这一段十分具有参考价值。不过有些背景资料得提供给各位参考。别忘了:
作者是美国人,是以该地为背景,且留意一下他所服务的公司是做什麽的..
...:-)唉!国内有这麽多的专业顾问公司吗?:-<
少数人会说:程式撰写标准只是「理想」而已,但在上述的组织机构中,它仍有其必
要性。
底下的FAQs提供一些基本的指导惯例及风格。
========================================
Q83:我们的组织该以以往C的经验来决定程式撰写标准吗?
No!
不论你的C经验有多丰富,不论你有多高深的C能力,好的C程式员并不会让你
直接就成为好的C++程式员。从C移到C++并不仅是学习"++"的语法语意而已
,一个组织想达到OOP的境界,却未将"OO"的精神放进OOP里的话,只是自欺罢
了;会计的资产负债表会把他们的愚蠢显现出来。
C++程式撰写标准应该由C++专家来调整,不妨先在comp.lang.c++里头问问题(
但是不要用"codingstandard"这种字眼;只要这样子问:「这种技巧有何优缺点
?」)。找个能帮你避开陷阱的高手,上个练习课程,买程式库,看看「好的」程式
库是否合乎你的程式撰写标准。绝对不要光靠自己来制定标准,除非你对它已有某种
程度的把握。没有标准总比有烂标准好,因为不恰当的「官方说法」会让不够聪明的
平民难以追随。现在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