高度重視警告：使用編譯器的最高警告級別；因該要求構建是乾淨利落的（沒有警告）；理解所有警告。通過修改**而不是降低警告級別來排除警告；
1. 編譯器是你的朋友，如果它對某個構造發出警告，這經常說明你的**中存在潛在問題；
2. 排除警告的正確做法：
(1)把它弄清楚；
(2)改寫**以排除警告，並使**閱讀者和編譯器都能更加清楚，**是按照編寫者意圖執行的；
3. 即使程式一開始似乎能夠正確執行，也還是要這樣做；即使你能肯定警告是良性的，任然要這樣做；因為良性警告的後面可能隱藏著未來指向真正危險的警告；
常見特定警告問題：
1. 第三方標頭檔案：無法修改的庫標頭檔案可能包含引起警告(可能是良性的)的構造；
(1)可以用自己的包含原標頭檔案的版本將此檔案包裝起來，並有選擇地為該作用域關閉煩人的警告，然後再整個專案的其他地方包含此包裝檔案；
(2) note:各種編譯器的警告控制語句並不一樣
2.未使用的函式引數；
(1) 檢查一下，確認確實不需要使用該函式引數(比如，這可能是乙個為了未來擴充套件而設的佔位符)，如果確實不需要，直接刪除函式引數名就可以了；
3.定義了從未使用過的變數；經常可以通過插入乙個變來那個本身的求值表示式，使編譯器不再報警；
locklock;
lock;
4.變數使用前可能未經初始化；…初始化變數；
5.遺漏了return語句：
(1) 有時候編譯器會要求每個分支都有乙個return語句，即使控制流可能永遠也不會到達函式的結尾(比如：無限迴圈，throw語句，其他的返回形式等)；
(2) 例如：沒有default情況的switch語句不太適應變化，應該加上執行assert(false)的default情況；
6.有符號/無符號數不匹配；
(1) 通常沒有必要對符號不同的整數進行比較和賦值；因該改變所操作的變數的型別，從而使變數匹配；
(2) 最壞的情況下，要插入乙個顯示的強制轉換；
例外情況：
有時候編譯器可能會發出煩人的或者虛假的警告(即純屬雜訊的警告)，但又沒有提供消除的方法，這時忙於修改**解決這個警告可能是勞而無功或者事半功倍的；如果遇到了這種罕見的情形，作為團隊決定，應該避免對純粹無益的警告再做無用功：單獨禁用這個警告，但是要盡可能在區域性禁用，並且編寫乙個清晰的注釋，說明為什麼必須禁用；
C 程式設計規範 組織和策略問題
第0條 不要拘泥於小節 又名 了解那些東西不應該標準化 只規定需要規定的事情 不要強制施加個人喜好或者過時的做法。詳細 1 應該使用縮進來體現 的結構。建議每個縮排使用4個空格或者設定編輯器的製表符大小為4個空格，並且應該在每個檔案中保持一致。2 應該保證 行的長度有利於閱讀。建議每行不超過10個單...
C 程式設計規範之組織和策略問題
組織和策略問題 第0條 不要拘泥於小節 了解哪些東西不應該標準化 摘要 只規定需要規定的事情 不要強制施加個人喜好或者過時的做法。程式的編寫存在一些準則是必要的，例如命名準則，但沒有必要要求所有人都遵守這些，否則條條框框太多，否則限制了語言的能力。函式並不是單入口單出口，雖然表面上看是的。第1條 在...
C 程式設計規範101讀書筆記（1）組織和策略問題
這部分主要涉及 質量控制 第0條 不要拘泥小節 風格一致 1 縮排體現 結構 2 行長度不要影響閱讀 3 使用一致的命名規範 4 編寫有用的注釋 第1條 在高告警級別乾淨利落地編譯 1 第三方標頭檔案 pragma warning push pragma warning disable 4516 p...