• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 1656 days ago, the information mentioned may be changed or developed.
 |
1
赞成
|
1 |
461da73cApr 21, 2022
2
C++ 的很难推动，本想推行 ci 自动格式化检查，一直都有人反对，很难推动下去。大家乐此不疲的 review 的时候 comment 格式化问题。
|
 |
3
持续集成加代码格式检测可解忧
|
 |
DonaidTrumpApr 21, 2022
4
赞成
|
 |
5
这个问题不大吧，自己自动格式化 1 秒的事。
|
 |
6
赞成，但是老项目是真的不敢 format ，一个 format 下去杀伤范围过于大了……
|
 |
7
@cmdOptionKana 😂 主要是老项目，格式化的时候，一大片，review 简直要了老命。
|
 |
8
人生苦短，请用 gofmt
|
 |
RocketerApr 21, 2022 via iPhone
11
ci 加格式检查只会查本次改动的文件，老文件不影响的
|
|
12
@461da73c idea 有这个功能，但是上下文识别总是出问题，每次都会 format 更大的范围，一不留神就把一大坨东西都给 format 掉了，只能把自己改的复制一下，revert 回去再粘贴上，后来就真的把 format 快捷键扣了不敢用了……
|
 |
VegetableApr 21, 2022
13
其实是 leader 的问题...
|
 |
14
记一次坑。用 ide 格式化触发未知 bug ，这导致提交代码前编译正常，格式化后提交代码项目编译就挂了。。
|
 |
nightwitchApr 21, 2022
15
|
 |
xiangyuecnApr 21, 2022
17
不是所有代码都适合去做格式化🐶
|
|
RocketerApr 21, 2022 via iPhone
18
说到底，格式化的问题都是历史问题，如果一直强制格式化，也就没那些问题了。
|
 |
20
@chendy 我们都是接手时专门提个点先把库格式化了再上手就没这问题了，不过要保证格式化不会出错而且所有人规则相同
以前在大公司工作格式化一行代码都要独立出来提 commit ，不然直接拒掉 |
 |
21
看来你是没吃过亏，编辑器远没那么智能，有时一个格式化快捷键按下去，后果很严重。
|
 |
FranzKafka95Apr 21, 2022 via Android
23
关于 C++格式化的，我推动我们团队做的一套体系，目前来看还不错。大家可以看看 https://coderfan.net/how-to-unify-code-stytle-in-c-or-c-plus-plus-html.html
|
 |
HankLuApr 22, 2022
24
完蛋，我写一行格式化一次，我是不是有病啊
|
 |
c0xt30aApr 22, 2022
25
格式化有时候还是个人的审美品味，没有一个固定的标准。
譬如下边的 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); } } ``` |
 |
26
以我的经验来说，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%的话，那么多出来的空白符会使这一行溢出。 |
 |
yagamilApr 22, 2022
27
golang 保存是自动格式化
|
 |
28
@a1562619919 最近也踩过这个坑, 前端打包脚本里面用字符串截取去获取某个值(比如: env="dev" ), 格式化的时候 双引号被格式化成单引号了, 导致获取环境的脚本失败.
|
 |
miceanApr 22, 2022
29
从来都是手动格式化。。。。
|
 |
unco020511Apr 22, 2022
30
然后你帮他们一格式化,就显示一堆你的提交,同事就会问,你改啥了提交这么多,别把我的功能改坏了
|
 |
CodeCodeStudyApr 22, 2022
31
自己写的代码要格式化，但是别人写的就不要修改了，免得出问题了要背锅
|
 |
showmethetalkApr 22, 2022
32
@HankLu 我也有这个病，写完一行就按下 ctrl+alt+l 、ctrl+alt+o
|
 |
Narcissu5Apr 22, 2022
33
所以 Go 在这方面真的很有遇见性
|
 |
lisongeeeApr 22, 2022
34
可以用 git hook 做代码格式化
|
 |
archxmApr 22, 2022
35
好一个不接受反驳。
|
 |
36
@chendy 这种格式化之后逻辑都会出问题的代码，那是该有多烂啊...
|
|
37
@461da73c 我在 review 代码的时候，如果发现没格式化的，一律打回。
|
|
38
@cmdOptionKana
@seers @Rocketer @Rocketer @lisongeee 我是从 eclipse 时代就开始写代码的，当时还没有自动格式化功能，和自动报错功能，当时我就养成了一个我认为非常好的习惯，写代码的时候手不能闲下来，一闲下来就会按 ctrl + shift + f 、ctrl + s 。 虽然现在用 idea 了，有自动保存的功能了，这个习惯还是保留着。 |
|
39
@Narcissu5 gofmt 很好用。
|
 |
alanhe421Apr 22, 2022
40
hook precommit 辅助下
|
 |
TorpedoApr 22, 2022
41
确实，我觉得格式化是比 lint 更的要求。而且实现成本很低
|
 |
bootvueApr 22, 2022
42
前后端代码 不 按照 我的习惯 格式化的都是垃圾
|
 |
joesonwApr 22, 2022 via iPhone
43
之前接手项目的时候，找了一个时间点，上 lint ，大家一起停下来修 lint ，修好了再继续。
|
 |
whusnoopyApr 22, 2022
44
|
 |
hay0577Apr 22, 2022
45
写代码不写注释的都是垃圾。不接受反驳
|
 |
newmlpApr 22, 2022
46
op 还是太年轻，好吧，我是辣鸡
|
 |
nuanshenApr 22, 2022
47
我格式化了，但是别人合并代码的时候骂了我一段还把我格式化的回滚了，为什么有人能接受代码写的歪七扭八的啊
|
 |
wtfdsyApr 22, 2022
48
一直在坚持代码格式化，不过提交的时候可以用公司的标准格式化一下再提交吧
|
 |
zerofancyApr 22, 2022
49
安卓开发。有时 IDE 不能正确识别出使用，然后把 import 给删掉。比如涉及 Support 库和 AndroidX 共存的模块。
另外前人没格的俺也不敢格，到时一查最近 commit log 都我的，一来影响定位原始修改，二来有时出问题还会被拉过去。 自己负责的模块和文件随便格。 |
 |
IsaacYoungApr 22, 2022
50
一个 format 下去 接下来有问题全来找你 狗头
|
|
t1xLM63evRKUbpMhApr 22, 2022
51
既然不接受反驳，你讲出来做什么呢。
|
|
52
@joesonw 优秀，将代码优化好，能给后面的开发工作提升不少效率。
|
|
53
@ftiasch 表明态度
|
|
54
@nuanshen 你应该骂回去，程序员要刚一点。
|
 |
DanswermeApr 22, 2022
55
之前接手过一个 php 项目，js 里面穿插各种 php 变量，改完之后习惯性的快捷键格式化了一下，然后项目就炸穿了。火速撤回之后发现是格式化把模版语法全部给破坏了。
|
 |
56
写代码还需要格式化的，都是垃圾，不接受反驳！（我都是写的时候空格什么的都带好了）
|
 |
3dwelcomeApr 22, 2022
57
有些人喜欢 if 后面大括号不换行，别且设立了项目格式化规范。
而我超级喜欢换行。 if () { vs if () { 最终我被打败了。 |
 |
mozhizhuApr 22, 2022
58
前端，现在提前走 git hook 挂 lint 检查，过不了的，连 commit 都做不到；当然……仅仅只是一个规范，不初始化安装 node_modules ，git hook 也没用
|
 |
n18255447846Apr 22, 2022
59
引战的帖子不被关，怎么还推上热榜了
|
 |
runoApr 22, 2022
60
@n18255447846 [v2 的各位都是帅哥美女] 这种也叫引战？
|
 |
lmmlwenApr 22, 2022
62
楼主还是太年轻，应该是没接触过大项目
|
 |
anonymousarApr 22, 2022
63
不说一个公司了 一个团队最基本的 起码应该把 clang-format 类似的检查作为编译的一个环节加到代码审核流程中去 过不了 lint 的代码直接进不去 review 环节。
|
|
64
@anonymousar 知己啊。
|
|
65
@lmmlwen 年轻不好么。
|
|
66
@n18255447846 这种也叫引战吗？
|
 |
siteshenApr 22, 2022
67
项目中我都是用零配置的格式化工具（最多配置个 maxLine = 100 ）：
clang-format gofmt black beautifier |
 |
MrzhsApr 22, 2022
68
ctrl + clt + l
|
 |
duan602728596Apr 22, 2022
69
所以说还是直接上 lint 比较好
|
 |
ytmsdyApr 22, 2022
72
老代码你直接一键快捷格式化，差不多 80%的代码都动了，后期完全没法对 git 记录。往往都会放弃！
|
 |
CloutainApr 22, 2022
73
都会格式化吧，关键是什么样的格式才是好格式
|
 |
leeyomApr 22, 2022
74
一个格式化，结果几百个改动，git 提交的时候，一堆冲突，所以，最好的办法是只选中自己的改的代码部分格式化
|
 |
recherstApr 22, 2022
75
赞成
|
 |
link1994Apr 22, 2022
76
Ctrl Alt L
针好用 |
 |
techstayApr 22, 2022
77
支持，代码格式化本来就属于项目质量控制的一部分，不仅要强制格式化，还要用工具严格控制整个项目的风格。我现在看到一些比较冷门的语言没有格式化功能，学都懒得学了。
|
 |
dengshenApr 22, 2022 via iPhone
78
失焦自动保存+格式化+热更新
|
 |
AllenHuaApr 23, 2022 via iPhone
80
破事水。这年头写代码还有谁不格式化，不遵循各种 lint ？换个厂吧。另外老项目另说……
|
 |
DlinApr 23, 2022 via Android
82
是的。一个 30 多岁的老开发，也不知道格式化一下。每次我去改代码，习惯性 c+s+l 。
|
Select Language