簽入高品質程式碼的方針
下列清單提供了數個簽入高品質程式碼的方針。
必要條件
堅持高品質的簽入。
不要在程式碼簽入期間接受低劣的品質，在產品週期的後半段這將會造成許多問題。 要知道小組通常不會修正太複雜、太模糊或是在產品週期中太晚發現的問題。
使用檢查清單。
追蹤常犯的錯誤，並拿來做為將來程式碼的檢查清單。 您可以從群組或部門常犯的一般性錯誤開始，然後將此清單個人化以供您使用。
進行程式碼檢閱。
程式碼檢閱讓您有機會說明並深入了解自己的程式碼，並且讓其他人也能重新檢閱這個程式碼。
撰寫單元測試。
確定品質的最佳方法，是撰寫可用來驗證資料和演算法，並確定先前的錯誤不會再犯的測試。 單元測試共有四種：
正面單元測試：以預期的方式執行程式碼，並驗證正確的結果。
負面單元測試：刻意誤用程式碼，驗證穩定性和適當的錯誤處理。
壓力測試 (Stress Test)：將程式碼壓榨至極限，以求找出不易發現的資源、時間或可重新進入 (Reentrant) 的錯誤。
錯誤插入測試：公開 (Expose) 錯誤處理的異常。
如需詳細資訊，請參閱針對現有的程式碼建立和執行單元測試。
使用程式碼分析工具。
要早期攔截 Bug 的最簡單方式，是提高編譯器的警告層級並使用程式碼分析工具。 重點是永遠不要忽略警告，並修正程式碼。
如需詳細資訊，請參閱使用程式碼分析進行 Managed 程式碼品質分析。
不要在原始程式碼中使用不當的語言。
在原始程式碼中，絕對不能有任何不當的語言和參考。 世界各地的客戶對於某些片語或名稱非常的敏感，特別是牽涉到狀況不明的政治實體時。 請搜尋原始程式碼中政治敏感的參考和語言，然後報告相關的錯誤。
建立工作項目。
不要忘記未完成的工作，務必為 TODO、REVIEW、BUG 和 UNDONE 註解建立工作項目。 如需詳細資訊，請參閱 建立工作項目。
請避免
沒有規格的功能。
規格未撰寫完成前，請不要撰寫程式碼。 請先撰寫規格並加以檢閱， 因為沒有規格，測試小組就不可能知道什麼是運作正常，什麼是異常。 如果您在沒有規格的情況下就撰寫程式碼，則小組成員可能會彼此誤解，或是誤解客戶需求，最後發行出品質低劣的產品。 如需詳細資訊，請參閱計劃和追蹤專案。
已到達第一個階段中期，卻還沒有產品安裝程式。
測試小組必須想辦法在電腦上安裝這個產品，即使只是原型 (Prototype) 的安裝程式也可以。 如需詳細資訊，請參閱建置應用程式。
建議使用
使用一致的程式碼撰寫風格。
當整個小組都以相同的風格撰寫程式碼時，這個產品便具有可讀性、一致性、可維護性以及整體的品質。 方針本身的細節則沒有那麼重要， 重要的是建立某些方針並且讓小組忠實地遵循此方針。 選擇任一風格的主要好處，是一致性以及辨識程式碼模式的方便性。 所以請選擇並使用某一個風格即可。
在撰寫程式碼之前，先撰寫單元測試。
測試優先的開發是快速開發和極限程式設計 (Extreme Programming) 的關鍵方法。 先撰寫單元測試，便可以達成下列品質目標：
確定已撰寫單元測試。
確定可以輕易地測試程式碼，這通常可以得到較佳的程式碼結合，模組之間的耦合也會較寬鬆。
通常藉由先決定要如何測試設計，就可以為工作找到適當的設計方式。
如需詳細資訊，請參閱針對現有的程式碼建立和執行單元測試。
讓程式碼能夠移植到其他平台。
針對可移植性來設計和撰寫程式碼，可以讓程式碼更穩固，即使從未打算在另一個平台上使用這個程式碼。 當程式碼具有可移植性時，您可以：
做比較好的假設。
對於資料型別和設計的意圖更加清楚。
確定程式碼對於未來新平台的支援程度更佳。
將現有的程式碼重構為較小的函式。
重構可以讓舊的程式碼重生。 嘗試修正大型的舊系統可能會很困難，因為某些部分的互動過於複雜，您可能連變更註解都很吃力。
若要成功地重構，則必須先加入強大的單元測試，確定重構程式碼不會產生新的錯誤。 接著，將大型函式分割為幾組較小的函式集合，但是不變更其功能。 方針是：
每個較小的函式應該只執行一種工作，例如使用者介面、資料庫存取、單一介面的 COM 互動等等。
完成重構子系統中所有的函式後，您可以變更個別的小函式，而不會影響整個系統。 可以一次新增、移除或加強一個函式的功能。
如需詳細資訊，請參閱重構類別和型別 (類別設計工具)。
檢閱現有的程式碼。
Bug 通常會集中在特定的模組內。 當新的程式碼沒有 Bug，但是舊程式碼的某些模組中含有許多錯誤時，只要檢閱這些模組即可。 如果新程式碼和舊程式碼過度糾結，則重構通常有助於解決問題。
如需詳細資訊，請參閱使用程式碼分析進行 Managed 程式碼品質分析。
在偵錯工具中逐步執行所有的程式碼路徑。
驗證程式碼的最佳方式之一，就是在偵錯工具中逐步執行這個程式碼。 對於每一行程式碼，驗證您所預期的結果確實發生。 在偵錯工具中逐步執行所有的程式碼路徑，就像逐行進行的單元測試。 這個程序雖然單調，但是可以有效地驗證所期望的行為。
不建議事項
使用需求文件做為規格。
不要試著從需求文件去解讀規格。 您的解讀可能和產品規劃經理或軟體測試人員的解讀不同。 如果解讀不同，則實作就不會符合其他人的期望。