各位的编辑器公司有统一的设定要求吗？

[kensoz]

比如换行自动触发 tab，tab 为 4 个空格,

亦或者是团队统一使用 vs code 统一 eslint 规则等等。

如果没有以上的要求，查看 git 差分或 review 代码的时候怎么解决 tab 长度不一样，eslint 规则不统一的问题？

[shakukansp]

prettier . --write

[LokiSharp]

CI 跑一遍 lint 不符合规则的拒绝合并

[bthulu]

没有的, 一团乱麻, 自己格式化

[ericls]

CI 的责任

[nevin47]

这种 CodingStyle 的问题都是人工规定+review+CI

[ericls]

@nevin47 不要人工干预代码 style 会浪费大量时间 。如果 review 里面出现了代码风格问题 只能说明 pre-commit 没设置好 或者 CI 美设置好

[nevin47]

@ericls #6 大部分还是要靠 CI，但是有些 CI 不是特别好设置，例如十六进制的数据，一般 CI 都会放行，需要人工判定一下是否是 magic number 的滥用，或者是本身临时使用 /特定含义数字

[ericls]

@nevin47 这种的确 我们一般会有注释去皮 disable linter. Review 的时候重点关注这种例外

[Vegetable]

前端好办啊，eslint+prettier+husky，比如这个项目

https://github.com/anncwb/vue-vben-admin

常见的语言都有解决方案，极端的 GO 直接内置了 fmt，松散的比如 java 大家一般都是用 ide 格式化，其实也有流行的 formatter，不太好用是真的。

保证在 commit 之前触发一次格式化就 ok 了。

[kensoz]

@Vegetable 感谢回复。像 java 用 ide 格式化的话，那就事前需要统一 ide 和 ide 设置吧

[ericls]

@kensoz 不同的 ide 也可以用 .editorconfig 或者在 pre-commit 的 hook 里面做 lint

[Vegetable]

@kensoz java 大家选择 idea 的概率太高，以至于五六个人的团队大家默认都选了 idea，愉快的避免了这个问题

[Vegetable]

@kensoz IDE 的格式化规则也是可以配置的，但是的的确确会出现不同 IDE 对同一套规则格式化的结果不同的情况。所以这方面对于团队 leader 活着相应负责人来说，还是有点工作量的。

[lance86]

@Vegetable 楼上提到的 同一份 .editorconfig 也会不同 ide 不同么？ idea 应该自带支持的

[chiu]

目前公司范围的没有，各个 team 有各自的 < Code Style Guide >, 但没有编辑器设定统一这种程度，因为使用什么编辑器也不是统一的。

[nightwitch]

项目根目录放一个.clang-format，没有 format 就提 pull request 的 CI 会直接拒绝。
其他语言大抵也有类似的格式化工具

[lrvy]

主要用 Golang， 提交前一把梭 `go mod tidy && goimports -l -w . && gofmt -s -w . `

[yolee599]

tab 统一格式化为 4 个空格，否则拒绝提交

[Rache1]

EditorConfig

[dayeye2006199]

这个一般由 linter 和 formatter 处理。编辑器不管这事儿