本頁面假設您已熟悉 Bazel，並提供有關建構專案的規範和建議，讓您充分利用 Bazel 的功能。
整體目標如下：
- 使用精細依附元件，允許平行處理和增量處理。
- 確保依附元件封裝良好。
- 讓程式碼結構化且易於測試。
- 建立易於理解及維護的建構設定。
這些準則並非必要條件：少數專案可以符合 全部都沒問題如 lint 的 man 頁面所述，「如果有人能製作出在嚴格檢查下不會產生錯誤的實際程式，我們會頒發特別獎勵。」但是，應盡可能採用這些原則 應該讓專案更容易閱讀、不容易出錯，同時加快建構速度。
本頁面將採用 此 RFC。
執行建構作業和測試
專案應一律能夠在穩定分支中順利執行 bazel build //... 和 bazel test //...。必要的目標
但請勿在特定情況下建構 (例如需要特定建構
或不在特定平台上發布內容、需要授權協議)
盡可能明確加入標記 (例如「requires-osx」)。這個
標記可讓您以更精細的方式篩選目標
「手動」標記並方便他人檢查 BUILD 檔案
目標的限制
第三方依附元件
您可以宣告第三方依附元件：
- 請在
MODULE.bazel檔案中將這些 API 宣告為遠端存放區。 - 或者，您也可以將這些檔案放在工作區目錄下的
third_party/目錄中。
取決於二進位檔
盡可能以原始碼建構所有內容。這通常意味著
如此一來，與其依附於程式庫 some-library.so 時，您都可以建立
BUILD 檔案，並從來源建構 some-library.so，然後依附於
目標。
一律從原始碼建構，可確保建構作業不會使用會執行以下程式碼的程式庫： 並使用不相容的旗標或不同架構來建構。此外， 例如涵蓋範圍、靜態分析或動態分析 都會對原始碼造成影響
版本管理
盡可能從最新版本建構所有程式碼。版本須為
，請避免在目標名稱中加入版本 (例如 //guava、
並非 //guava-20.0)。這項命名方式可簡化程式庫的更新程序 (只使用一個
目標需要更新)。這也更能抵禦菱形依附元件問題：如果一個程式庫依附於 guava-19.0，另一個程式庫依附於 guava-20.0，那麼程式庫可能會嘗試依附兩個不同的版本。如果您建立了誤導性別名，將兩個目標指向一個 guava 程式庫，那麼 BUILD 檔案就會造成誤導。
使用 .bazelrc 檔案
如需專案專屬選項，請使用 workspace/.bazelrc 的設定檔 (請參閱 bazelrc 格式)。
如果您要為專案支援其他使用者選項，但「並未」 需要檢查原始碼控管位置，請包含以下這一行：
try-import %workspace%/user.bazelrc
在您的 workspace/.bazelrc 中 (或任何其他檔案名稱)
並將 user.bazelrc 新增到您的 .gitignore。
套件
包含可建構檔案的每個目錄都應為一個套件。如果BUILD
檔案指的是子目錄 (例如 srcs = ["a/b/C.java"]) 中的檔案
一個符號，表示 BUILD 檔案應新增至該子目錄。這個結構存在的時間越長，就越有可能無意中建立循環依附元件，目標的範圍會逐漸擴大，而且需要更新的反向依附元件數量也會增加。