这是一个创建于 1990 天前的主题，其中的信息可能已经有所发展或是发生改变。
没错，我说的就是我的同事，我也不要求你有多牛逼，提交的代码不能有任何警告，我只是要求提交代码前按一下快捷键格式化对齐代码，每次都说 okok,然后依然我行我素。
重点是有时候这个同事可能没空，我要修改他的代码，一堆没对齐代码附加一大堆警告，作为一个强迫症看得想死。
提交的代码连格式化对齐都不做，到底是什么让他走上码农的道路...
 |
1
HuHui 2019-06-11 15:25:31 +08:00 via Android  1
可以强制格式化的
|
 |
2
cstj0505 2019-06-11 15:29:44 +08:00 1
1.可能他不知道怎么做。
2.如果他不知道，告诉他，现在不管他以前知不知道，他现在知道了 3.他既然知道了，你就可以要求他做一下，反正也不难 |
 |
3
d553296416 2019-06-11 15:31:18 +08:00 1
比起写的代码各种内存泄露影响程序稳定性而言，，这种可有可无的事情我能忍，反正最后可以用工具一键格式化
|
 |
4
merin96 2019-06-11 15:36:06 +08:00 1
1.和气地告诉他 IDE 自动格式化多么好用,在哪儿设置, 什么不知道?我来帮你搞
2.严肃地告诉他我有强迫症你不格式化每次拉代码我都很难受以致于无法工作 3.git 钩子设置一些静态检查工具,不过不让合 难度一次上升 |
 |
5
qinyusen 2019-06-11 15:38:32 +08:00
git 强制格式化提交。。。
|
 |
6
amwyyyy 2019-06-11 15:39:35 +08:00
我也不能忍，我有强迫症，代码必须对齐、不能有警告。
|
 |
7
passerbytiny 2019-06-11 15:53:37 +08:00
论软件过程管理或者软件质量管理的重要性。
|
 |
8
hydrionz 2019-06-11 15:54:06 +08:00
每次拉下来新代码，直接先格式化以后提交.....次数多了你们领导也会恨那个不格式化代码就提交的人....
|
 |
9
cedoo22 2019-06-11 16:11:24 +08:00
IDEA: Ctrl+Alt+L Eclipse: Ctrl+Alt+F Git: 格式化提交
|
 |
10
chendy 2019-06-11 16:12:14 +08:00 1
如果他用的 idea 的话…直接让他把提交框上的”格式化”打钩就行了
|
 |
11
Caballarii 2019-06-11 16:17:06 +08:00 11
这哥们需要去写两笔 python
|
 |
12
chmaple 2019-06-11 16:19:43 +08:00 2
如果是 IDEA，并且用自带 GIT 工具提交的话，可以大家都导入一份同样的格式化配置文件，然后提交 commint and push 的时候勾选上自动格式化的选项
话说格式化是必须的，而且规则要一致，不然两个人改了同一个类，提交或者有冲突的时候会疯。 |
 |
14
classyk 2019-06-11 16:24:30 +08:00
自己格式化一下再看也很容易，如果自己觉得难，那也就不要怪别人觉得难啦
|
 |
15
la2la 2019-06-11 16:24:42 +08:00
@Caballarii +1
|
 |
16
msg7086 2019-06-11 16:25:04 +08:00 via Android
我初中写代码的时候就被教导说格式要正确。从此养成良好的习惯。
|
 |
19
shingle 2019-06-11 16:44:58 +08:00 via Android
想到了我的前同事，写 go 语言都不格式化代码的。。。配个 goftm 又不是什么麻烦事
|
 |
20
metrue 2019-06-11 16:46:48 +08:00
PR review 的时候 request change 就好了，不 approve 烂代码。
|
 |
22
jasonyang9 2019-06-11 16:48:58 +08:00
Python：？？？
|
 |
23
Greendays 2019-06-11 16:53:42 +08:00
联动这歌帖子，估计楼主同事在里头支招呢 233
https://www.v2ex.com/t/572728#reply28 |
 |
24
Takamine 2019-06-11 17:18:11 +08:00
格式化，不是...一键格式化吗。
而且格式化的配置文件大家不应该要求是统一的吗。 |
 |
25
hstdt 2019-06-11 17:26:28 +08:00 via iPhone
使用 lint 工具辅助代码质量控制，要是能和绩效挂钩的话，就更容易让他写好代码了。
|
 |
27
mamahaha 2019-06-11 17:47:49 +08:00
我想大多数创造代码的人都会打草稿，做几行就会进行一下输出测试，这个时候考滤的是逻辑，代码块测试通过了才会考虑格式。
如果代码是 copy 来的，大段大段的不用测试，就像整理代码一样，这样的一上来就会把格式做到位吧。 |
 |
28
EminemW 2019-06-11 19:47:58 +08:00 via iPhone
你可以告诉他怎么快速格式化，他可能不会，，
|
 |
29
linvaux 2019-06-11 20:12:09 +08:00 via Android
幸亏这哥们儿不是写了 js 的
|
 |
30
Bartholomew 2019-06-11 20:19:23 +08:00
文件保存就自动格式化 vscode 有这个设置
|
 |
34
kaedea 2019-06-11 22:22:37 +08:00 via Android
最近刚回在做代码格式规范的工作，说一下感受。
这个问题看上去简单，要做到强制还真的难： 1. 历史代码一大堆格式问题，全部修改不现实 2. 每个 ide 自带的格式化标准都不太一样 3. 代码风格每个人见解都有出入，很难完全统一 其实主要原因还是团队整体技术氛围，我之前呆过的团队，工程师文化比较好，大家普遍对代码质量有追求，所以风格统一上容易达成一致，新来的人代码写得搓也会在 rv 环节被纠正过来。 现在呆的团队代码风格就有点野了，历史包袱太重，大家普遍各顾个的，突然间要求别人要换成另一种写法，大概率会被白眼... 最终的方案是： 1. 合入检查只做修改、新增代码的格式规范 2. 代码规范只强制做结构上（空格、缩进）和命名上的要求单单这样就已经检查出不少问题 3. 通过 EditorConfig 统一项目的基本配置 4. 引导开发多使用 ide 的自动补全功能，已经提交代码前自觉格式化代码 但是我还是觉得之前团队的状态才是根本的解决方案啊，无奈。 |
 |
35
Vincex 2019-06-11 22:28:19 +08:00
可以用 githook 提交时自动格式化
|
|
36
kaedea 2019-06-11 22:29:26 +08:00 via Android
@kaedea
除了这个代码规范，类似的还有 git log 规范和 git merge /rebase 基本用法规范的问题，也真是难控制，通过 git hook 做强制检查容易，要引导别人按到新的流程去做事才是最难的。 个人觉得一个团队的整体工程师文化水平，从以上三点就能看出个大概了。 现在的感觉就是，要培养用户的习惯真的很难啊。 |
 |
37
loading 2019-06-11 22:32:55 +08:00 via Android
我提交 c 语言 pr 时我的空格都要按坏了……用工具又会因为里面用到的宏啊什么的对齐得乱七八糟。
我越来越喜欢 go 了。 |
 |
38
FakeLeung 2019-06-11 22:40:50 +08:00
怎么可以不经意的让我同事看到这篇？
|
|
40
msg7086 2019-06-11 22:50:15 +08:00
@kaedea git merge rebase 规范这个实在是太难了。
太多的程序员不会用 git，只知道无脑 commit/merge/branch。 |
 |
41
Meltdown 2019-06-11 23:07:10 +08:00 via Android
我遇到的情况是公司没有统一规定代码风格，然后有些人可能用了 IDE 的自动格式化，有些文件明明明大家都没做什么修改，这些 IDE 造成的格式修改却老是被提交来提交去，随便一个提交就搞成了几千行
|
 |
42
ginjedoad 2019-06-11 23:31:32 +08:00
golang 从来不需要对齐，直接保存对齐了....
|
 |
43
SingeeKing 2019-06-11 23:34:08 +08:00
配个 git pre-commit hook
|
 |
44
chen2019 2019-06-11 23:35:10 +08:00
ide 直接格式化就行了 管他对不对齐
|
 |
45
zhuzhibin 2019-06-11 23:59:42 +08:00 via iPhone
代码规范意识很重要 团队里可以定义一套代码规范 大家都要遵循这么一套规范 就没那么多鸟事了
|
 |
46
lincanbin 2019-06-12 00:02:22 +08:00 via Android
你需要做的是加 ci，ci 里跑 lint 做格式检查，格式出问题系统自动发邮件给他然后通报全组。
|
 |
47
hastyfish 2019-06-12 00:06:49 +08:00 via Android
vim gg=G
|
 |
48
dangyuluo 2019-06-12 00:30:23 +08:00
CI 是干什么的？你管他对齐对不齐？
|
 |
50
FrankHB 2019-06-12 00:56:20 +08:00
KPI 掌嘴。
|
|
51
FrankHB 2019-06-12 00:57:17 +08:00
@chen2019 污染 commit history 可能引起更严重的强迫症。
（我最烦的是 autocrlf 之类一时半会儿还未必马上能发现的……） |
 |
52
nanxiaobei 2019-06-12 01:00:20 +08:00
上 Prettier 完事
|
 |
53
russian 2019-06-12 01:04:05 +08:00
@linvaux 哈哈哈。我以前维护一个 nodejs 工程，接受一个人的活，然后这个人根本不知道什么叫 async，后调函数一直硬刚，最多好像嵌套了 7，8 个括号
|
 |
55
MonoLogueChi 2019-06-12 01:13:58 +08:00 via Android
@hydrionz 你去改他的代码，格式化，可能会造成冲突
|
 |
56
magicdawn 2019-06-12 12:46:47 +08:00 via iPhone
嗯知道 node 的话用这个
npm i -g yo generator-magicdawn yo magicdawn:add-config 会添加 husky prettier lint-staged |
 |
57
HangoX 2019-06-12 13:10:48 +08:00
我在 ci 上加了逻辑，格式不过不让合并，然后共享自动化格式的配置文件。问题解决了
|
 |
58
buhi 2019-06-12 18:05:28 +08:00
1. 有这么多时间折腾代码哪里应该有一个空格, 哪里应该换行, 花同样的时间在其他地方不是更好吗?
2. 这个格式化本来就没有一个四海皆准的规范, 都是见仁见智, 举两个例子比如函数体的左大括号应不应该换行, 缩进应该用 tab 还是空格. 假如你定了一个标准, 然后强制同事去遵守, 然后因为跟同事的习惯不符影响了开发效率, 会不会有一种钦定的意思? |
Select Language