C++编程规范101条规则与最佳实践0.pdf

C++编程规范101条规则与最佳实践0.pdf

ID:52242237

大小:608.83 KB

页数:12页

时间:2020-03-25

C++编程规范101条规则与最佳实践0.pdf_第1页
C++编程规范101条规则与最佳实践0.pdf_第2页
C++编程规范101条规则与最佳实践0.pdf_第3页
C++编程规范101条规则与最佳实践0.pdf_第4页
C++编程规范101条规则与最佳实践0.pdf_第5页
C++编程规范101条规则与最佳实践0.pdf_第6页
C++编程规范101条规则与最佳实践0.pdf_第7页
C++编程规范101条规则与最佳实践0.pdf_第8页
C++编程规范101条规则与最佳实践0.pdf_第9页
C++编程规范101条规则与最佳实践0.pdf_第10页
资源描述:

《C++编程规范101条规则与最佳实践0.pdf》由会员上传分享,免费在线阅读,更多相关内容在行业资料-天天文库

1、组织和策略问题如果人们按照程序员编程的方式修建房屋,那么一只啄木鸟就能毁灭整个文明。①——GeraldWeinberg为了遵从C和C++的伟大传统,我们从0开始编号。首要的指导原则,也就是第0条,阐明了我们认为对编程规范而言最为基本的建议。接下来,这个导论性部分的其他条款将主要讲述几个精心选择的基本问题,这些问题大多数与代码本身并没有直接关系,它们讨论的是编写坚实代码所必需的工具和技术。本部分中我们选出的最有价值条款是第0条:“不要拘泥于小节”(又名:“了解哪些东西不应该标准化”)。①GeraldWeinberg是著名的软件思想家(他自称thinker

2、),因《程序开发心理学》等书名世,以对软件开发的深刻洞察而著称。——译者注2C++编程规范:101条规则、准则与最佳实践第0条不要拘泥于小节①(又名:了解哪些东西不应该标准化)摘要只规定需要规定的事情:不要强制施加个人喜好或者过时的做法。讨论有些问题只是个人喜好,并不影响程序的正确性或者可读性,所以这些问题不应该出现在编程规范中。任何专业程序员都可以很容易地阅读和编写与其习惯的格式略有不同的代码。应该在每个源文件乃至每个项目中都使用一致的格式,因为同一段代码中要在几种编程风格(style)之间换来换去是很不舒服的。但是无需在多个项目或者整个公司范围内强

3、制实施一致的格式。下面列举了几种常见的情况,在这里重要的不是设定规则,而是与所维护的文件中已经使用的体例保持一致。不要规定缩进多少,应该规定要用缩进来体现代码的结构。缩进空格的数量可以遵照个人习惯,但是至少在每个文件中应该保持一致。不要强制行的具体长度,应该保证代码行的长度有利于阅读。可以遵照个人习惯来决定行长,但是不要过长。研究表明,文字长度不超过10个单词最利于阅读。不要在命名方面规定过多,应该规定的是使用一致的命名规范。只有两点是必需的:(1)永远不要使用“晦涩的名称”,即以下划线开始或者包含双下划线的名称;(2)总是使用形如ONLY_UP

4、PERCASE_NAMES的全大写字母表示宏,不要考虑使用常见的词或者缩略语作为宏的名称(包括常见的模板参数,比如T和U;像#defineTanything这样的代码是极容易混淆的)。此外,应该使用一致的、有意义的名称,遵循文件的或者模块的规范。(如果你无法决定自己的命名规范,可以尝试如下命名规则:类、函数和枚举的名称形如LikeThis,即单词首字母大写;变量名形如likeThis,即第一个单词首字母小写,第二个单词首字母大写;私有成员变量名形如likeThis_;宏名称形如LIKE_THIS。)不要规定注释风格(除非需要使用工具从特定的体例中提取

5、出文档),应该编写有用的注释。尽可能编写代码而不是写注释(比如,见第16条)。不要在注释中重复写代码语义,这样很容易产生不一致。应该编写的是解释方法和原理的说明性注释。最后,不要尝试强制实施过时的规则(见例3和例4),即使它们曾经在一些比较陈旧的编程规范中出现过。示例①出自RichardCarlson的畅销书Don’tSweattheSmallStuff…andIt’sallSmallStuff,中文版译名为《别为小事抓狂》。——译者注组织和策略问题3例1大括号的位置。以下代码在可读性方面并不存在区别:voidusing_k_and_r_style()

6、{//„„}①voidputting_each_brace_on_its_own_line(){//„„}②voidor_putting_each_brace_on_its_own_line_indented(){//„„}③任何一个专业程序员都能够毫无困难地阅读和编写这些体例中的任何一种。但是应该保持一致:不要随意地或者以容易混淆作用域嵌套关系的方式放置大括号,要尽量遵循每个文件中已经使用的体例。在本书中,对大括号位置的选择主要是为了能够在编辑允许范围内得到最佳可读性。例2空格与制表符。有些团队禁用制表符(比如[BoostLRG]),因为不同的编辑器

7、中制表符的设定是不同的,如果使用不当,会将缩进变为“缩出”和“无缩进”。其他同样受人尊敬的团队则允许使用制表符,并采取了一些能够避免其潜在缺陷的规定。这都是合理的,其实只要保持一致即可:如果允许使用制表符,那么要确保团队成员维护彼此的代码时,不会影响代码的清晰和可读性(见第6条)。如果不允许使用制表符,应该允许编辑器在读入源文件时将空格转换为制表符,使用户能够在编辑器中使用制表符,但是在将文件写回时,一定要将制表符转换回空格。例3匈牙利记法。将类型信息并入变量名的记法,是混用了类型不安全语言(特别是C)中的设施,这在面向对象语言中是可以存在的,但是有害

8、无益,在泛型编程中则根本不可行。所以,任何C++编程规范都不应该要求使用匈牙利记法,而在规范中

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。