When reviewing merge requests I always find it hard to bring up issues with code style.

在审查合并请求时，我总是发现很难提出代码样式问题。

Code style is subjective. I have my own opinion of what clean code looks like, and that opinion may be very different from the opinion of the rest of my team.

代码风格是主观的。 我对干净代码的外观有自己的看法，这种看法可能与我团队其他成员的看法截然不同。

There are also different levels of code style. On one end of the spectrum we have best practices that directly affect the maintainability of the code going forward:

也有不同级别的代码样式。 一方面，我们拥有直接影响以后代码可维护性的最佳实践：

• Small methods
  小方法
• Descriptive method names
  描述性方法名称

On the other end we have issues that do not necessarily make the code harder to maintain, but often make the codebase more consistent and easier to read:

另一方面，我们遇到的问题并不一定会使代码更难维护，但通常会使代码库更一致且更易于阅读：

• Consistent indentation
  一致的缩进
• Wrapping long lines
  包装长行
• Avoiding walls of code
  避开代码墙

While I find it easy to comment on code that does not follow the best practices in the first group, I find it harder to send a merge request back to the author because of issues from the second group.

虽然我发现对不遵循第一组最佳实践的代码进行评论很容易，但是由于第二组的问题，我发现很难将合并请求发送回作者。

If the code works and the tests pass, is it worth delaying that feature because the author used tabs instead of spaces?

如果代码有效且测试通过，那么值得延迟该功能，因为作者使用制表符而不是空格吗？

This is where automation comes in. While it isn’t possible to automate everything, there are tools that can automatically detect code style violations and flag them during the coding process or during the build pipeline.

这是实现自动化的地方。虽然不可能实现全部自动化，但是有些工具可以自动检测代码样式违规并在编码过程中或在构建管道中对其进行标记。

Some tools can even automatically fix some code style violations.

有些工具甚至可以自动修复某些违反代码风格的问题。

In my opinion, the first step to implement these kinds of check