程式設計風格指南的使用要點在於提供乙個公共的編碼規範，所有人可以把精力集中在實現內容而不是表現形式上。我們給出了全域性的風格規範，但區域性的風格也很重要，如果你在乙個檔案中新加的**和原有**風格相去甚遠的話，這就破壞了檔案本身的整體美觀也影響閱讀
前面說明的編碼習慣基本是強制性的，但所有優秀的規則都允許例外。
1. 現有不統一**（existing non-conformant code）
對於現有不符合既定程式設計風格的**可以網開一面。
當你修改使用其他風格的**時，為了與**原有風格保持一致可以不使用本指南約定。如果不放心可以與**原作者或現在的負責人員商討，記住，一致性包括原有的一致性。
1. windows**（windows code）
windows程式設計師有自己的編碼習慣，主要源於windows的一些標頭檔案和其他microsoft**。我們希望任何人都可以順利讀懂你的**，所以針對所有平台的c++編碼給出乙個單獨的指導方案。
如果你一直使用windows編碼風格的，這兒有必要重申一下某些你可能會忘記的指南（譯者注，我怎麼感覺像在被**:d）：
1) 不要使用匈牙利命名法（hungarian notation，如定義整型變數為inum），使用google命名約定，包括對原始檔使用.cc副檔名；
2) windows定義了很多原有內建型別的同義詞（譯者注，這一點，我也很反感），如dword、handle等等，在呼叫windows api時這是完全可以接受甚至鼓勵的，但還是盡量使用原來的c++型別，例如，使用const tchar *而不是lpctstr；
3) 使用microsoft visual c++進行編譯時，將警告級別設定為3或更高，並將所有warnings當作errors處理；
4) 不要使用#pragma once;作為包含保護，使用c++標準包含保護，包含保護的檔案路徑包含到專案樹頂層（譯者注，#include）；
5) 除非萬不得已，否則不使用任何不標準的擴充套件，如#pragma和__declspec，允許使用__declspec(dllimport)和__declspec(dllexport)，但必須通過dllimport和dllexport等巨集，以便其他人在共享使用這些**時容易放棄這些擴充套件。
在windows上，只有很少一些偶爾可以不遵守的規則：
1) 通常我們禁止使用多重繼承，但在使用com 和atl /wtl 類時可以使用多重繼承，為了執行com或atl/wtl類及其介面時可以使用多重實現繼承；
2) 雖然**中不應使用異常，但在atl和部分stl（包括visual c++的stl）中異常被廣泛使用，使用atl時，應定義_atl_no_exceptions以遮蔽異常，你要研究一下是否也遮蔽掉stl的異常，如果不遮蔽，開啟編譯器異常也可以，注意這只是為了編譯stl，自己仍然不要寫含異常處理的**；
3) 通常每個專案的每個原始檔中都包含乙個名為stdafx.h或precompile.h的標頭檔案方便標頭檔案預編譯，為了使**方便與其他專案共享，避免顯式包含此檔案（precompile.cc除外），使用編譯器選項/fi以自動包含；
4) 通常名為resource.h、且只包含巨集的資源標頭檔案，不必拘泥於此風格指南。
參考常識，保持一致。
編輯**時，花點時間看看專案中的其他**並確定其風格，如果其他**if語句中使用空格，那麼你也要使用。如果其中的注釋用星號（*）圍成乙個盒子狀，你也這樣做：
/**********************************程式設計風格指南的使用要點在於提供乙個公共的編碼規範，所有人可以把精力集中在實現內容而不是表現形式上。我們給出了全域性的風格規範，但區域性的風格也 很重要，如果你在乙個檔案中新加的**和原有**風格相去甚遠的話，這就破壞了檔案本身的整體美觀也影響閱讀，所以要盡量避免。* some comments are here.
* there may be many lines.
**********************************/
好了，關於編碼風格寫的差不多了，**本身才是更有趣的，盡情享受吧！
benjy weinberger
craig silverstein
gregory eitzmann
mark mentovai
tashana landray
Google C 程式設計風格指南
每乙個c 程式設計師都知道，c 具有很多強大的語言特性，但這種強大不可避免的導致它的複雜，這種複雜會使得 更易於出現bug 難於閱讀和維護。本指南的目的是通過詳細闡述在c 編碼時要怎樣寫 不要怎樣寫來規避其複雜性。這些規則可在允許 有效使用c 語言特性的同時使其易於管理。使用前置宣告，盡量少.h檔案...
Google C 程式設計風格指南
越來越發現一致的程式設計風格的重要性，於是把google的c 程式設計風格指南看了一遍，這裡記錄下於自己有益的rules。當規則有多個選擇時，這裡只記錄個人習慣的用法，並不代表它是唯一的用法。google style guide google開源專案風格指南 命名管理是最重要的一致性規則，因此我把它...
Google C 程式設計風格指南（五） 命名約定
最重要的一致性規則是命名管理，命名風格直接可以直接確定命名實體是 型別 變數 函式 常量 巨集等等，無需查詢實體宣告，我們大腦中的模式匹配引擎依賴於這些命名規則。命名規則具有一定隨意性，但相比按個人喜好命名，一致性更重要，所以不管你怎麼想，規則總歸是規則。1.通用命名規則 general namin...