C++语言常见问题解答3.docVIP

C++语言常见问题解答3 Ｃ＋＋语言常见问题解答(三） ＝＝ Ｐａｒｔ ３／４ ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ comp.lang.c++ Frequently Asked Questions list (with answers, fortunately). Copyright (C) 1991-96 Marshall P. Cline, Ph.D. Posting 3 of 4. Posting #1 explains copying permissions, (no)warranty, table-of-contents, etc ============================= ■□ 第１４节：程式风格指导 ============================= 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, Dont Build.)。」买程式库， 买训练课程，买开发工具，买谘询顾问。想靠自学来达到成功的工具厂商及应用／系 统厂商，都会发现成功很困难。 【译注】这一段十分具有参考价值。不过有些背景资料得提供给各位参考。别忘了： 作者是美国人，是以该地为背景，且留意一下他所服务的公司是做什麽的.. ... :-) 唉！国内有这麽多的专业顾问公司吗？ :- 少数人会说：程式撰写标准只是「理想」而已，但在上述的组织机构中，它仍有其必 要性。 底下的 FAQs 提供一些基本的指导惯例及风格。 ======================================== Q83：我们的组织该以以往 C 的经验来决定程式撰写标准吗？ No! 不论你的 C 经验有多丰富，不论你有多高深的 C 能力，好的 C 程式员并不会让你 直接就成为好的 C++ 程式员。从 C 移到 C++ 并不仅是学习 ++ 的语法语意而已 ，一个组织想达到 OOP 的境界，却未将 OO 的精神放进 OOP 里的话，只是自欺罢 了；会计的资产负债表会把他们的愚蠢显现出来。 C++ 程式撰写标准应该由 C++ 专家来调整，不妨先在 comp.lang.c++ 里头问问题（ 但是不要用 coding standard 这种字眼；只要这样子问：「这种技巧有何优缺点 ？」）。找个能帮你避开陷阱的高手，上个训练课程，买程式库，看看「好的」程式 库是否合乎你的程式撰写标准。绝对不要光靠自己来制定标准，除非你对它已有