C++语言常见问题解答(3)

2008-02-23 05:34:52来源:互联网 阅读 ()

新老客户大回馈,云服务器低至5折

== Part 3/4  ============================ ============================= 
■□ 第14节:程式风格指导 
============================= 
 
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"? 
 
假如您已有个惯例,就用他吧。假如没有,看看您的编译器,看他用的是哪一种。典 

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇: C++语言常见问题解答(2)

下一篇: C++语言常见问题解答(4)