在研究項目團隊協作開發的情況下這裡的團隊協作也適合於應用項目的開發），編程時應該強調的一個重要方面是程序的易讀性，在保證軟件速度等性能指標能滿足用戶需求的情況下，能讓其他程序員容易讀懂你所編寫的程序。
若研究項目小組的所有開發人員都遵循統一的、鮮明的一套編程風格，可以讓協作者、後繼者和自己一目了然，在很短的時間內看清楚程序結構，理解設計的思路，大大提高代碼的可讀性、可重用性、程序健壯性、可移植性、可維護性。
制定本編程規范的目的是為了提高軟件開發效率及所開發軟件的可維護性，提高軟件的質量。本規范由程序風格、命名規范、注釋規范、程序健壯性、可移植性、錯誤處理以及軟件的模塊化規范等部分組成。
本軟件開發規范適合討論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++應用列表”裡面列出來的那些地方。
底線是：如果把C++中的諸多不必要的復雜性去掉，留下那些本質的，重要的語言特性，簡化語言模型，消除歷史包袱。即便是C++的反對者也許也很難找到理由說“我還是不用C++”。在我看來，一個真正從實踐意義上理性反對使用C++的人只有一個理由：C++的復雜性帶來的混亂抵消乃至超過了C++的抽象機制和庫在他的特定項目中）帶來的好處。
值得注意的是，這裡需要避免一個陷阱，就是一旦人們認定了“C++不好”，那麼這個理由就會“長出自己的腳來”，即，就算我們拿掉C++的復雜性，他們可能也會堅持還是不用C++，並為之找一堆理由。
我假定你不是這樣的人。不過，也許最可能的是他會說：“問題是我們今天用的C++並非如此簡潔），你的假設不成立。”是的，我的假設不成立。但雖然我們無法消除復雜性，我們實際上是可以容易地避開復雜性，避短揚長的。這也是本文的要點，容我後面再詳述。
