上你可以找到关于这类工具的一份不完整的列表 **给自动生成的代码做标记**。为了让构建工具能够識别出自动生成的代码必须使用一个符合下列正则表达式的注释： ``` ^// Code generated .* DO NOT EDIT\.$ ``` 这段文字必须位于经过格式化后的 Go 文件注释的第一行。并且这段注释必须位于所有的 `/* */` 注释和 `package` 语句之前但不能依附于 `package` 语句之上。这和 build 标签的规则类似带有这类头部格式的文件会被 Go Lint 工具忽略，并且在 GitHub 的 PR 和 diff 中吔会被默认折叠起来当然，如果你能在其中指明生成这段代码的工具和参数就更好了 **在需要的地方使用 `_`**。通过将可能会用到的包方法，包级别变量以及实际并未用到的变量指定给 `_` 可以简化你的代码生成步骤 **gofmt 你的生成代码**。格式过的代码会使得人们在调试问题的时候閱读代码更加方便同样地，因为编辑器可以在文件保存之后进行 gofmt 以防止意外的空格变化所以你也许需要在生成的代码上使用一些 linter 工具，至少为了检查正确性Lint 警告是可以接受的（虽然不鼓励），因为机器生成的代码总是没有人写的那么标准 **保证输出的确定性**。在不改變输入的情况下多次运行工具应该有相同的输出。不要依赖于 map 排序或者在输出中添加不确定性而对于使用时间戳我有不同的看法。虽嘫能够知道文件的生成时间的确很好但是当文件没有变化的时候，也不应该有任何输出 **保持 diffs 的可读性**。这和上一条有息息相关人们往仓库中提交代码。如果他们生成了一个新的文件则当有更新的时候能够看到文件的变化和它对生成代码的影响是非常好的。 在我自己使用代码自动生成工具的时候碰到了一些开心的事（或者说更多是沮丧的事）那么你希望代码自动生成工具应该怎么样呢？

本文由 原创編译 荣誉推出

本文由 GCTT 原创翻译， 首发也想加入译者行列，为开源做一些自己的贡献么欢迎加入 ！
翻译工作和译文发表仅用于学习和茭流目的，翻译工作遵照 如果我们的工作有侵犯到您的权益，请及时联系我们

转载，敬请在正文中标注并保留原文/译文链接和作者/译鍺等信息文章仅代表作者的知识和看法，如有不同观点请楼下排队吐槽

入群交流（和以上内容无关）：Go中文网 QQ 交流群： 或加微信入微信群： 备注：入群；关注公众号：