TL;DRDeepSource Transformers在你的拉取请求上自动运行代码格式化器，如Black、Gfmt等，并提交格式化的代码，而不需要任何努力。你可以在这里试试 - 它对开源和最多3个私人仓库是免费的。
代码风格惯例对开发者来说很重要。而且也有很好的理由--遵守一致的风格可以提高代码的可读性，让任何正在使用它的人都能更快、更彻底地理解现有的代码，并能轻松地添加新的东西。一款软件一生中40%-80%的成本都用于维护，因此投资于保持代码的整洁是值得的。
虽然，达成一个风格协议要比表面上看起来要难得多。大多数开发者都有自己的个人偏好，他们极力维护这些偏好。但同样的人也同意，在每一个新的拉动请求上争论风格惯例只是在浪费时间。他们只是想把这件事做完。
幸运的是，代码格式化器出现了，拯救了他们。这一切都从Gofmt开始，它是Go编程语言的自动代码格式化器。它提供了一种有主见但一致的Go代码格式化方式，其主要目标之一是完全消除关于格式化决定的任何争议。它成功了!Gofmt很快就被所有编写Go语言的人采用，成为事实。有些人甚至称其为该语言的最佳功能，为现代编程中代码风格约定的重要性提供了巨大的合法性。很快，像Black和Prettier这样的工具出现了，为其他编程语言带来了同样的理念。
手动代码格式化工作流程的问题
如果你没有使用花哨的IDE或预提交钩子，你仍然需要手动运行代码格式化器。这就造成了一些问题。
- 你的团队中有人可能忘记在代码上运行Gofmt或Black。不是每个人都使用IDE，或者即使他们使用，也没有安装格式化器并正确配置为保存时自动格式化。
- 如果你把格式化器作为CI步骤来运行，如果代码还没有被格式化，CI构建就会失败。然后有人需要手动拉出最新的分支，应用格式化，然后再推送。
- 如果格式化的改变是作为现有PR的一部分，那么就很难审查代码，或者有意义地恢复这些改变。
很明显，这场战斗只赢了一半。代码格式化器自动将代码格式化为整个代码库的一致风格。运行格式化器仍然是手动的和混乱的。
我在Hacker News上看到了关于linters和代码格式化器的讨论，当时有一条评论引起了我的注意。
"我也喜欢只是敲打代码，保存，然后让我的编辑器为我清理格式化。"-tlrobinson
tlrobinson是对的。代码格式化，尽管对大多数开发者来说很重要，但也很乏味，而且可以完全自动化。所以我们决定把自动化比编辑器更早一步，直接在你的GitHub（和GitLab）上的PR工作流程中实现。我们建立了Transfomers--一种在每个拉动请求上自动运行代码格式化器并提交修改的方法，只需零点点击。以下是它的工作原理。
第1步：在DeepSource上启用一个转化器
只要在配置文件中添加两行，就可以了。如果你愿意，你也可以启用多个变压器。
第2步：安装DeepSource Autofix
如果你使用GitHub，配置DeepSource以自动提交修改到你的PR。
然后完成!今后，每次有人在仓库上提出拉动请求，DeepSource就会自动提交最新提交后的格式化修改。
模仿你写代码的方式
在设计变形器的工作方式时，我们试图使工作流程尽量接近开发人员在理想情况下实际运行代码格式器的方式。
- 变形器通过对转换后的代码与原始代码进行上下文感知的比较，智能地找出是否有必要运行代码格式化器。如果它没有发现任何需要格式化的代码，它就会干净利落地存在，而不做任何提交--只是通知开发者没有什么需要转换的。
- 如果需要运行格式化程序，Transformers会创建一个带有格式化修改的单独提交，并将其添加到pull-request的提交树中。这确保了提交历史在逻辑上是合理的，而且如果需要的话，将来很容易挑出或恢复一些变化。
- 如果启用了多个格式化器，就有可能出现一个格式化器覆盖了其他格式化器的修改。这可能会导致不一致的情况。变形器通过检测同一文件中是否有多个格式化器的覆盖，然后在该文件上重复运行格式化，直到达到一致的状态来处理这个问题。
现在GitHub上有150K+的手动提交，标题中包含"run black"。而这仅仅是来自开源的。
我们相信开发者在这样的工作流程上浪费了太多的时间，而这些工作流程完全可以可靠地自动化。DeepSource的使命是帮助开发人员发布好的代码，其中一部分可以通过自动化所有可以可靠地自动化的东西来实现，为每个开发人员节省大量的时间。
如果你写Python或Go代码，今天就给变形金刚一个机会。它对开源是免费的，对多达3个私有仓库也是免费的→deepsource.io/signup
