写代码不格式化的，都是垃圾，不接受反驳！

[astrorobbie]

赞成

[461da73c]

C++ 的很难推动，本想推行 ci 自动格式化检查，一直都有人反对，很难推动下去。大家乐此不疲的 review 的时候 comment 格式化问题。

[jenlors]

持续集成加代码格式检测可解忧

[tulongtou]

赞成

[cmdOptionKana]

这个问题不大吧，自己自动格式化 1 秒的事。

[chendy]

赞成，但是老项目是真的不敢 format ，一个 format 下去杀伤范围过于大了……

[Rache1]

@cmdOptionKana 😂 主要是老项目，格式化的时候，一大片，review 简直要了老命。

[seers]

人生苦短，请用 gofmt

[461da73c]

@chendy 可以只格式化 patch 上下文的行。

[yuruizhe]

@Rache1 格式化又不会改变逻辑…除非 py2 到 py3 这种，老代码 print 没括号

[Rocketer]

ci 加格式检查只会查本次改动的文件，老文件不影响的

[chendy]

@461da73c idea 有这个功能，但是上下文识别总是出问题，每次都会 format 更大的范围，一不留神就把一大坨东西都给 format 掉了，只能把自己改的复制一下，revert 回去再粘贴上，后来就真的把 format 快捷键扣了不敢用了……

[Vegetable]

其实是 leader 的问题...

[a1562619919]

记一次坑。用 ide 格式化触发未知 bug ，这导致提交代码前编译正常，格式化后提交代码项目编译就挂了。。

[nightwitch]

@a1562619919
如果是 C++的话，代码或者注释里有中文的话老版本的 MSVC 会出现这种奇奇怪怪的 bug(GBK 编码问题)。
新版本的加 /utf-8 flag 就行。

[ALLROBOT]

@chendy 好奇怎么会会杀害力巨大呢？格式化不改变代码运行逻辑吧

[xiangyuecn]

不是所有代码都适合去做格式化🐶

[Rocketer]

说到底，格式化的问题都是历史问题，如果一直强制格式化，也就没那些问题了。

[Tyanboot]

@ALLROBOT 杀伤力巨大可能是指你一格式化，直接几千几万行的改动，到时候混在 diff 里面头都大了。

[rekulas]

@chendy 我们都是接手时专门提个点先把库格式化了再上手就没这问题了，不过要保证格式化不会出错而且所有人规则相同
以前在大公司工作格式化一行代码都要独立出来提 commit ，不然直接拒掉

[falcon05]

看来你是没吃过亏，编辑器远没那么智能，有时一个格式化快捷键按下去，后果很严重。

[461da73c]

@chendy clang-format 不存在你说的问题。

[FranzKafka95]

关于 C++格式化的，我推动我们团队做的一套体系，目前来看还不错。大家可以看看 https://coderfan.net/how-to-unify-code-stytle-in-c-or-c-plus-plus-html.html

[HankLu]

完蛋，我写一行格式化一次，我是不是有病啊

[c0xt30a]

格式化有时候还是个人的审美品味，没有一个固定的标准。
譬如下边的 duff's device ，在不同的程序员手里可能会有不同的格式化方式，很难论个高下。

```c
void send( int* to, int* from, int count)
{
int n = (count + 7) / 8;
switch (count % 8) {
case 0: do { *to = *from++;
case 7: *to = *from++;
case 6: *to = *from++;
case 5: *to = *from++;
case 4: *to = *from++;
case 3: *to = *from++;
case 2: *to = *from++;
case 1: *to = *from++;
} while (--n > 0);
}
}
```

[dcsuibian]

以我的经验来说，Java 、C#随便格。
Python 想格就格（个人不是很喜欢 PEP8 ，感觉每行太短了）
js 也可以格，但要小心规则一致性，要不然容易搞出一大堆 eslint 错误。最好用 prettier 配合好。

目前唯一注意到的会影响运行的例子好像是出在 html 格式化上，但也比较极端。
<ul><li>...</li><li>...</li><li>...</li><li>...</li></ul>
被格式化成
<ul>
<li>...</li>
<li>...</li>
<li>...</li>
<li>...</li>
</ul>
如果此时 li 被设置成宽度 25%的话，那么多出来的空白符会使这一行溢出。

[yagamil]

golang 保存是自动格式化

[answerhuang]

@a1562619919 最近也踩过这个坑, 前端打包脚本里面用字符串截取去获取某个值(比如: env="dev" ), 格式化的时候 双引号被格式化成单引号了, 导致获取环境的脚本失败.

[micean]

从来都是手动格式化。。。。

[unco020511]

然后你帮他们一格式化,就显示一堆你的提交,同事就会问,你改啥了提交这么多,别把我的功能改坏了

[CodeCodeStudy]

自己写的代码要格式化，但是别人写的就不要修改了，免得出问题了要背锅

[liut2016]

@HankLu 我也有这个病，写完一行就按下 ctrl+alt+l 、ctrl+alt+o

[Narcissu5]

所以 Go 在这方面真的很有遇见性

[lisongeee]

可以用 git hook 做代码格式化

[archxm]

好一个不接受反驳。

[helloworld1024]

@chendy 这种格式化之后逻辑都会出问题的代码，那是该有多烂啊...

[helloworld1024]

@461da73c 我在 review 代码的时候，如果发现没格式化的，一律打回。

[helloworld1024]

@cmdOptionKana
@seers
@Rocketer
@Rocketer
@lisongeee

我是从 eclipse 时代就开始写代码的，当时还没有自动格式化功能，和自动报错功能，当时我就养成了一个我认为非常好的习惯，写代码的时候手不能闲下来，一闲下来就会按 ctrl + shift + f 、ctrl + s 。

虽然现在用 idea 了，有自动保存的功能了，这个习惯还是保留着。

[helloworld1024]

@Narcissu5 gofmt 很好用。

[alanhe421]

hook precommit 辅助下

[Torpedo]

确实，我觉得格式化是比 lint 更的要求。而且实现成本很低

[bootvue]

前后端代码 不 按照 我的习惯 格式化的都是垃圾

[joesonw]

之前接手项目的时候，找了一个时间点，上 lint ，大家一起停下来修 lint ，修好了再继续。

[whusnoopy]

#10 @yuruizhe HTML 会有格式化后影响结果的情况，参考 #26 @dcsuibian 的举例，对 HTML 来说，任意多连续空白符会需要占一个空格字宽，很多样式处理时都要把上层设置 font-size:0 来规避

[hay313955795]

写代码不写注释的都是垃圾。不接受反驳

[newmlp]

op 还是太年轻，好吧，我是辣鸡

[nuanshen]

我格式化了，但是别人合并代码的时候骂了我一段还把我格式化的回滚了，为什么有人能接受代码写的歪七扭八的啊

[wtfdsy]

一直在坚持代码格式化，不过提交的时候可以用公司的标准格式化一下再提交吧

[zerofancy]

安卓开发。有时 IDE 不能正确识别出使用，然后把 import 给删掉。比如涉及 Support 库和 AndroidX 共存的模块。
另外前人没格的俺也不敢格，到时一查最近 commit log 都我的，一来影响定位原始修改，二来有时出问题还会被拉过去。
自己负责的模块和文件随便格。

[IsaacYoung]

一个 format 下去 接下来有问题全来找你 狗头

[t1xLM63evRKUbpMh]

既然不接受反驳，你讲出来做什么呢。

[helloworld1024]

@joesonw 优秀，将代码优化好，能给后面的开发工作提升不少效率。

[helloworld1024]

@ftiasch 表明态度

[helloworld1024]

@nuanshen 你应该骂回去，程序员要刚一点。

[Danswerme]

之前接手过一个 php 项目，js 里面穿插各种 php 变量，改完之后习惯性的快捷键格式化了一下，然后项目就炸穿了。火速撤回之后发现是格式化把模版语法全部给破坏了。

[eGlhb2Jhb2Jhbw]

写代码还需要格式化的，都是垃圾，不接受反驳！（我都是写的时候空格什么的都带好了）

[3dwelcome]

有些人喜欢 if 后面大括号不换行，别且设立了项目格式化规范。
而我超级喜欢换行。

if () {

vs

if ()
{

最终我被打败了。

[mozhizhu]

前端，现在提前走 git hook 挂 lint 检查，过不了的，连 commit 都做不到；当然……仅仅只是一个规范，不初始化安装 node_modules ，git hook 也没用

[n18255447846]

引战的帖子不被关，怎么还推上热榜了

[q1angch0u]

@n18255447846 [v2 的各位都是帅哥美女] 这种也叫引战？

[thedrwu]

@yuruizhe 格式化虽然不改逻辑，但是会毁 git bame

[lmmlwen]

楼主还是太年轻，应该是没接触过大项目

[anonymousar]

不说一个公司了 一个团队最基本的 起码应该把 clang-format 类似的检查作为编译的一个环节加到代码审核流程中去 过不了 lint 的代码直接进不去 review 环节。

[helloworld1024]

@anonymousar 知己啊。

[helloworld1024]

@lmmlwen 年轻不好么。

[helloworld1024]

@n18255447846 这种也叫引战吗？

[siteshen]

项目中我都是用零配置的格式化工具（最多配置个 maxLine = 100 ）：

clang-format
gofmt
black
beautifier

[Mrzhs]

ctrl + clt + l

[duan602728596]

所以说还是直接上 lint 比较好

[96412hj]

@chendy 那你代码得好几 w 行了吧？

[yuruizhe]

@Danswerme 哪个格式化工具啊…居然无法识别模版…说出来给大家提个醒吧…

[ytmsdy]

老代码你直接一键快捷格式化，差不多 80%的代码都动了，后期完全没法对 git 记录。往往都会放弃！

[Cloutain]

都会格式化吧，关键是什么样的格式才是好格式

[leeyom]

一个格式化，结果几百个改动，git 提交的时候，一堆冲突，所以，最好的办法是只选中自己的改的代码部分格式化

[recherst]

赞成

[link1994]

Ctrl Alt L
针好用

[techstay]

支持，代码格式化本来就属于项目质量控制的一部分，不仅要强制格式化，还要用工具严格控制整个项目的风格。我现在看到一些比较冷门的语言没有格式化功能，学都懒得学了。

[dengshen]

失焦自动保存+格式化+热更新

[ghouleztt]

@chendy ctrl+shift+l 可以只格式化选中的部分

[AllenHua]

破事水。这年头写代码还有谁不格式化，不遵循各种 lint ？换个厂吧。另外老项目另说……

[GTim]

@leeyom git 对比的时候可以忽略空白

[Dlin]

是的。一个 30 多岁的老开发，也不知道格式化一下。每次我去改代码，习惯性 c+s+l 。