這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。`//go:generate` 的引入使得 Go 語言在構建過程中整合自動代碼產生工具更加簡單。`stringer` 使得編寫重複代碼更輕鬆，而 `yacc` 和 `ragel` 這類程式則讓最佳化解析器的產生變得可能。在 [GoGenerateTools](https://github.com/golang/go/wiki/GoGenerateTools) 上你可以找到關於這類工具的一份不完整的列表。**給自動產生的程式碼做標記**。為了讓構建工具能夠識別出自動產生的程式碼，必須使用一個符合下列Regex的注釋：```^// Code generated .* DO NOT EDIT\.$```這段文字必須位於經過格式化後的 Go 檔案注釋的第一行。並且這段注釋必須位於所有的 `/* */` 注釋和 `package` 語句之前，但不能依附於 `package` 語句之上。這和 build 標籤的規則類似。帶有這類頭部格式的檔案會被 Go Lint 工具忽略，並且在 GitHub 的 PR 和 diff 中也會被預設摺疊起來。當然，如果你能在其中指明產生這段代碼的工具和參數就更好了。**在需要的地方使用 `_`**。通過將可能會用到的包，方法，包層級變數以及實際並未用到的變數指定給 `_` 可以簡化你的代碼產生步驟。**gofmt 你的產生代碼**。格式過的代碼會使得人們在調試問題的時候閱讀代碼更加方便。同樣地，因為編輯器可以在檔案儲存之後進行 gofmt 以防止意外的空格變化，所以你也許需要在產生的程式碼上使用一些 linter 工具，至少為了檢查正確性。Lint 警告是可以接受的（雖然不鼓勵），因為機器產生的程式碼總是沒有人寫的那麼標準。**保證輸出的確定性**。在不改變輸入的情況下，多次運行工具應該有相同的輸出。不要依賴於 map 排序或者在輸出中添加不確定性。而對於使用時間戳我有不同的看法。雖然能夠知道檔案的產生時間的確很好，但是當檔案沒有變化的時候，也不應該有任何輸出。**保持 diffs 的可讀性**。這和上一條有息息相關。人們往倉庫中提交代碼。如果他們產生了一個新的檔案，則當有更新的時候能夠看到檔案的變化和它對產生代碼的影響是非常好的。在我自己使用代碼自動產生工具的時候碰到了一些開心的事（或者說更多是沮喪的事）。那麼你希望代碼自動產生工具應該怎麼樣呢？
via: https://medium.com/@dgryski/five-nice-things-for-machine-generated-code-5335e67c1e36
作者：Damian Gryski 譯者：alfred-zhong 校對：rxcai
本文由 GCTT 原創編譯，Go語言中文網 榮譽推出
本文由 GCTT 原創翻譯，Go語言中文網 首發。也想加入譯者行列，為開源做一些自己的貢獻嗎？歡迎加入 GCTT！
翻譯工作和譯文發表僅用於學習和交流目的，翻譯工作遵照 CC-BY-NC-SA 協議規定，如果我們的工作有侵犯到您的權益，請及時聯絡我們。
歡迎遵照 CC-BY-NC-SA 協議規定 轉載，敬請在本文中標註並保留原文/譯文連結和作者/譯者等資訊。
文章僅代表作者的知識和看法，如有不同觀點，請樓下排隊吐槽
688 次點擊
