C++/C程序對函數的處理方式是不同的。extern “C”是使C++能夠調用C寫作的庫文件的一個手段，如果要對編譯器提示使用C的方式來處理函數的話，那麼就要使用extern “C”來說明。
若研究項目小組的所有開發人員都遵循統一的、鮮明的一套編程風格，可以讓協作者、後繼者和自己一目了然，在很短的時間內看清楚程序結構，理解設計的思路，大大提高代碼的可讀性、可重用性、程序健壯性、可移植性、可維護性。
制定本編程規范的目的是為了提高軟件開發效率及所開發軟件的可維護性，提高軟件的質量。本規范由程序風格、命名規范、注釋規范、程序健壯性、可移植性、錯誤處理以及軟件的模塊化規范等部分組成。
每個C++/C程序通常分為兩個文件。一個文件用於保存程序的聲明declaration），稱為頭文件。另一個文件用於保存程序的實現implementation），稱為定義definition）文件。
C++/C程序的頭文件以“.h”為後綴，C程序的定義文件以“.c”為後綴，C++程序的定義文件通常以“.cpp”為後綴也有一些系統以“.cc”或“.cxx”為後綴）。早期的編程語言如Basic、Fortran沒有頭文件的概念，C++/C語言的初學者雖然會用使用頭文件，但常常不明其理。這裡對頭文件的作用略作解釋：
1） 通過頭文件來調用庫功能。在很多場合，源代碼不便或不准）向用戶公布，只要向用戶提供頭文件和二進制的庫即可。用戶只需要按照頭文件中的接口聲明來調用庫功能，而不必關心接口怎麼實現的。編譯器會從庫中提取相應的代碼；
2） 頭文件能加強類型安全檢查。如果某個接口被實現或被使用時，其方式與頭文件中的聲明不一致，編譯器就會指出錯誤，這一簡單的規則能大大減輕程序員調試、改錯的負擔。assert不是一個倉促拼湊起來的宏。為了不在程序的Debug版本和Release版本引起差別，assert不應該產生任何副作用。
所以assert不是函數，而是宏。程序員可以把assert看成一個在任何系統狀態下都可以安全使用的無害測試手段。如果程序在assert處終止了，並不是說含有該assert的函數有錯誤，而是調用者出了差錯，assert可以幫助我們找到發生錯誤的原因。
絕大多數人都把細節太多或者用貶義詞來說就是“陰暗角落太多”）歸結為C++的本質問題，認為一切邪惡由此而生。也正因此，大約9月份的時候，Linus在郵件列表上說“C++/C程序是一門有思想包袱的語言；僅僅是為了讓程序員遠離C++，我也要用C”。這句短短的話在國內引起了很大的反應，最初是劉江轉了Linus的話，然後雲風和孟巖都發表了自己的看法；我也寫了一篇“Why C++”後來發給Bjarne，Bjarne對這篇文章做了一個友情評注）。
然而，這一通渾水攪過之後，我相信引起的變化未必很大。大多數原先的反對者能從中找出反對的理由，於是更加反對；大多數原先的贊同者也能從中找到贊同的理由，於是更加贊同；而剩下來的原先沒有明確意見的，看雙方各有各的道理，可能還是沒有頭緒。
