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

赞成

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

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

赞成

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

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

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

人生苦短，请用 gofmt

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

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

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

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

其实是 leader 的问题...

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

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

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

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

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

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

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

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

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

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

格式化有时候还是个人的审美品味，没有一个固定的标准。
譬如下边的 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);
}
}
```

以我的经验来说，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%的话，那么多出来的空白符会使这一行溢出。

golang 保存是自动格式化

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

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

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

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

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

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

可以用 git hook 做代码格式化

好一个不接受反驳。

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

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

@cmdOptionKana
@seers
@Rocketer
@Rocketer
@lisongeee

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

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

@Narcissu5 gofmt 很好用。

hook precommit 辅助下

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

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

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

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

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

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

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

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

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

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

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

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

@ftiasch 表明态度

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

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

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

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

if () {

vs

if ()
{

最终我被打败了。

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

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

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

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

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

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

@anonymousar 知己啊。

@lmmlwen 年轻不好么。

@n18255447846 这种也叫引战吗？

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

clang-format
gofmt
black
beautifier

ctrl + clt + l

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

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

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

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

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

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

赞成

Ctrl Alt L
针好用

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

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

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

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

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

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