C++编程规范：组织与策略问题
Posted 计算机科学的艺术
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了C++编程规范：组织与策略问题相关的知识，希望对你有一定的参考价值。
0
了解哪些东西不应该标准化
有些问题只是个人喜好，并不影响程序的正确性或者可读性，所以这些问题不应该出现在编程规范中。任何专业程序员都可以很容易地阅读和编写与其习惯的格式略有不同的代码。
应该在每个源文件乃至每个项目中都使用一致的格式，因为同一段代码中要在几种编程风格（ style ）之间换来换去是很不舒服的。但是无需在多个项目或者整个公司范围内强制实施一致的格式。
下面列举了几种常见的情况，在这里重要的不是设定规则，而是与所维护的文件中已经使用的体例保持一致。
不要规定缩进多
不要强制行的具体长度
不要在命名方面规定过多,应该规定的是使用一致的命名规范。
不要规定注释风格(除非需要使用工具从特定的体例中提取出文档)
最后，不要尝试强制实施过时的规则，即使它们曾经在一些比较陈旧的编程规范中出现过。
1
在高警告级别千净利落地进行编译
编译器是你的朋友。如果它对某个构造发出警告，一般表明代码中存有潜在的问题。
成功的构建应该是无声无息的（没有警告的）。如果不是这样，你很快就会养成不仔细查看输出的习惯，从而漏过真正的问题。
排除警告的正确做法是：把它弄清楚；然后，改写代码以排除警告，并使代码阅者和编译器都能更加清楚，代码是按编写者的意图执行的。
即使程序一开始似乎能够正确运行，也还是要这样做。即使你能够肯定警告是良性的，要这样做。因为良性警告的后面可能隐藏着未来指向真正危险的警告。
例外情况：
有时候，编译器可能会发出烦人的甚至虚假的警告（即纯属噪声的警告），但是又没有提供消除的方法，这时忙于修改代码解决这个警告可能是劳而无功或者事倍功半的。如果遇到了这种罕见的情形，作为团队决定，应该避免对纯粹无益的警告再做无用功：单独禁用这个警告，但是要尽可能在局部禁用，并且编写一个清晰的注释，说明为什么必须禁用。
2
使用自动构建系统
单操作的构建过程非常重要。它应该能将源文件可靠和可重复地转换为可以交付的软件包。现在已经有了大量自动构建工具，没有理由不用。所以，选择一种，用起来吧。
我们曾经见到不少开发单位忽略了构建系统“单操作”这一需求。有些开发单位认为，用鼠标四处点击几下，运行一些实用工具来注册 COM/CORBA服务器，手工复制一些文件，就是很不错的构建过程了。可是，我们都不应该将时间和精力浪费在机器可以干得更快更好的事情上。自动的、可靠的、单操作的构建是非常必要的。
成功的构建应该无声无息，不产生任何警告。理想的构建过程不会出现干扰，只会出现一条日志信息：“构建成功”。
构建有两种模式：增量构建和完全构建。增量构建只重新构建上次构建(可以是增量的或者完全的)以来发生改变的部分。注意：两次连续增量构建中的第二次构建不应该编写任何输出文件；否则，可能会出现依赖循环，构建系统也可能会执行不必要的操作（比如，编写假的肯定要丢弃的临时文件）。
一个项目的完全构建可能有不同形式。可以考虑通过改变许多基本特性，调整构建过程的参数，候选的特性包括目标架构，调试模式还是发布模式，以及范围（基本文件、所有文件、还是完整的安装文件）。一种构建设置能够生成产品的基本可执行文件和库,另一种设置可能还会生成附属文件，而完全构建则可能生成包括所有文件、第三方可重发行文件和安装代码在内的安装文件。
随着项目日渐发展，不使用自动构建所带来的成本也会逐渐増加。如果没有从一开始就使用自动构建，时间和资源的浪费就将无可避免。更糟糕的情况是，到了不得不使用自动构建的时候，你所面临的压力将比项目开始时大得多。
大型项目可能应该设置一个“构建管理员”，他的工作就是负责构建系统。
3
使用版本控制系统
几乎所有大一点的项目都需要不只一个开发人员和一周以上的开发时间。在这样的项目中，需要比较同一文件的各个历史版本，以确定修改是何时（以及/或者由谁）进行的；需要控制和管理源代码的变更。
如果有多个开发人员，他们将会并行地进行修改，可能会在同一时间修改同一文件的不同部分。此时，就需要能对文件进行自动登出/版本管理的工具了，有些情况下还需要并发编辑的合并功能。版本控制系统能够自动化和控制登出、版本管理及合并操作。版本控制系统能够比人工实施更快更正确。而且我们也不需要在管理琐事上浪费时间——编写软件才是我们的工作。
即使是单独工作的开发人员，也有脑子短路的瞬间，需要搞清楚何时为什么引入了某个错误或者进行了某个修改。我们都难免如此。版本控制系统能够自动地跟踪每个文件的历史，使我们能够“让时光倒流”。问题并不在于你是否需要从历史中寻找答案,而在于你何时需要。
不要破坏构建。版本控制系统中的代码必须总能构建成功。
由于目前能够找到大量的版本控制系统，我们没有任何借口将其拒之门外。最廉价也最流行的版本控制系统是 cvs 。这个工具非常灵活，提供了 TCP/IP访问功能，可以选择增强安全性（提供使用sh协议作为后端），可以通过脚本编程实现极佳的管理功能，甚至还有图形界面。许多其他的版本控制系统产品要么将cvs作为模仿的标准，要么是以其为基础再构建新的功能。
例外情况：
只有一个程序员且从头至尾只需一周的项目，可能不需要版本控制系统。
4
做代码审查
好的代码审査过程对开发团队有许多好处。
通过来自同伴的良性压力提高代码质量。
找出错误、不可移植的代码（如果适用）和潜在的扩展问题。
通过思想交流获得更好的设计和实现。
快速培养新同事和入门者。
在团队中形成共同的价值观和集体主义。
增强整体实力，提升自信心、动力和职业荣誉感。
许多开发单位现在既不奖励高质量的代码和高质量的团队，也不投入时间和资金予以鼓励。我们估计几年之内这种情况仍然会存在，但是趋势已经在缓慢变化，这部分是因为软件安全性需求的不断增加。代码审査恰恰有助于提高软件的安全性，而且还是内部培训的一种极佳方法(而且没有成本)
如果老板现在还不支持代码审查过程，那就先从提高管理层的认识做起，同时尽最大努力想各种办法腾出时间进行审査。这种时间是值得花的。
代码审査应该成为软件开发周期中的常规环节。如果能够与同事就奖惩制度达成一致，那就更好了。
代码审查无需太形式主义，最好通过书面形式进行能够更容易地跟踪你自己的过程，避免重复。
小结：我们知道这是老调重弹,但还是不得不说。我们的天性都讨厌代码审查,但是内心又有一个小小的天才程序员乐此不疲，因为它富于成效，而且能够获得更好的代码和更可靠的应用程序。
扫描二维码获取优质内容
计算机科学的艺术
以上是关于C++编程规范：组织与策略问题的主要内容，如果未能解决你的问题，请参考以下文章