在研究项目团队协作开发的情况下（这里的团队协作也适合于应用项目的开发），编程时应该强调的一个重要方面是程序的易读性，在保证软件速度等性能指标能满足用户需求的情况下，能让其他程序员容易读懂你所编写的程序。
若研究项目小组的所有开发人员都遵循统一的、鲜明的一套编程风格，可以让协作者、后继者和自己一目了然，在很短的时间内看清楚程序结构，理解设计的思路，大大提高代码的可读性、可重用性、程序健壮性、可移植性、可维护性。
制定本编程规范的目的是为了提高软件开发效率及所开发软件的可维护性，提高软件的质量。本规范由程序风格、命名规范、注释规范、程序健壮性、可移植性、错误处理以及软件的模块化规范等部分组成。
本软件开发规范适合讨论C/C++程序设计。
1 文件结构
每个C++/C程序通常分为两个文件。一个文件用于保存程序的声明（declaration），称为头文件。另一个文件用于保存程序的实现（implementation），称为定义（definition）文件。
C++/C程序的头文件以“.h”为后缀，C程序的定义文件以“.c”为后缀，C++程序的定义文件通常以“.cpp”为后缀（也有一些系统以“.cc”或“.cxx”为后缀）。
1.1 文件信息声明
文件信息声明位于头文件和定义文件的开头（参见示例1-1），主要内容有：
（1） 版权信息；
（2） 文件名称，项目代码，摘要，参考文献；
（3） 当前版本号，作者/修改者，完成日期；
（4） 版本历史信息；
（5） 主要函数描述。
显然，如果找不出要学习C++的理由，那么谈什么“正确的学习方法”等于是废话。 首先重复一句Bjarne的话：“我们的系统已经是极度复杂的了，为了避开C++的复杂性而干脆不用C++（Linus的做法），无异于因噎废食。”在所有可用C和C++的领域，C++都是比C更好的语言。
当我说“更好的”时候，我说的是C++拥有比C更安全的类型检查、更好的抽象机制、更优秀的库。当然，凡事都有例外，如果你做的项目1）不大。2）编码中用不到什么抽象机制，甚至ADT（抽象数据类型，例如std::complex这种不含多态和继承的）也用不到，RAII也用不到，异常也用不到。
3）你连基础库（如，简化资源管理的智能指针、智能容器）都用不着。那么也许你用C的确没问题；所以如果你的情况如此，不用和我争论，因为我无法反驳你。我们这里说的领域大致是Bjarne在“C++应用列表”里面列出来的那些地方。 #t#
底线是：如果把C++中的诸多不必要的复杂性去掉，留下那些本质的，重要的语言特性，简化语言模型，消除历史包袱。即便是C++的反对者也许也很难找到理由说“我还是不用C++”。在我看来，一个真正从实践意义上理性反对使用C++的人只有一个理由：C++的复杂性带来的混乱抵消乃至超过了C++的抽象机制和库（在他的特定项目中）带来的好处。
值得注意的是，这里需要避免一个陷阱，就是一旦人们认定了“C++不好”，那么这个理由就会“长出自己的脚来”，即，就算我们拿掉C++的复杂性，他们可能也会坚持还是不用C++，并为之找一堆理由。
我假定你不是这样的人。不过，也许最可能的是他会说：“问题是我们今天用的C++并非如此（简洁），你的假设不成立。”是的，我的假设不成立。但虽然我们无法消除复杂性，我们实际上是可以容易地避开复杂性，避短扬长的。这也是本文的要点，容我后面再详述。
