作者brucetu (sec)
看板Soft_Job
标题Re: [讨论] 写三元判断式code review被打枪
时间Wed Dec 14 13:54:02 2022
三元不能用 算还好了
我还遇过
a=1;
...
...
if (xxx) a=2;
不能这样写 请改成
if (xxx) { //还可以战一下这个{要不要去下一行
a=2;
}
以免有人没看到那个一行if後面有assign value
这种事情就是看话语权啦
每个人看code习惯不同
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 220.135.153.214 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1670997244.A.3F0.html
1F：推 NCUking: 什麽话语权 这是团队规范该做的好吗 12/14 14:10
2F：→ lazarus1121: 第一种写法正常人看到都会骂吧 12/14 14:24
3F：→ vi000246: 第一种写法比三元还差.. 12/14 14:25
4F：→ LFimi: 这只是coding style根本没统一而已吧 12/14 14:28
5F：嘘 BlueBird5566: 原来不只我讨厌第一种写法 12/14 14:32
6F：→ BlueBird5566: if(xxx) 12/14 14:33
7F：→ BlueBird5566: a=2; 12/14 14:33
8F：→ BlueBird5566: b=3; 12/14 14:33
9F：→ BlueBird5566: 如果是if(xxx) return、break就算了 上面这种更糟 12/14 14:34
10F：→ qwer338859: 第一种在干嘛....为啥不直接宣告在if上面要离那麽远 12/14 14:34
我的举例意思是a=1跟a=2中间有别的code啦
不是所有状况都可以先做完别的事情最後再来a=(cond)?1:2
这时候到底要写成if (cond) a=2;一行还是拆开有大括号
啊就看有权决定的人爽就好
11F：→ BlueBird5566: 还跟别行程式并排在一起 12/14 14:35
12F：推 stupid0319: style很漂亮的粪code,至少对公司说的过去 12/14 14:35
13F：→ alan3100: 第一个太烂了吧 为了缩排而缩排比三元更没意义 12/14 14:35
14F：→ qwer338859: 这是在讲缩排吗 这个不是讲好就好 12/14 14:37
15F：→ alan3100: 缩减行数 12/14 14:38
16F：→ qwer338859: 我们这边只要有if就强制加大夸号就算是空body也一样 12/14 14:38
17F：→ BlueBird5566: 有{}还是比较好啦 虽然现在CODE只有一行 未来要加 12/14 14:39
18F：→ alan3100: 如过以google java style来讲大夸号是必加不能省 12/14 14:40
19F：→ BlueBird5566: 其他行程式也比较不会出错 没{}的写法真的就装逼~ 12/14 14:40
20F：→ BlueBird5566: 刚学程式时也喜欢那些写短的code 好像越短越强 12/14 14:41
21F：→ alan3100: 第一种写法除非你以後绝对不会改到 不然维护上很常出错 12/14 14:41
22F：→ BlueBird5566: 但工作久了反而觉得可读性高的程式重要多了 12/14 14:41
23F：→ BlueBird5566: 之前写个回圈 同事还叫我把所有逻辑写在回圈里 说这 12/14 14:42
24F：→ shooter555: 我也讨厌if(xxx) a=2;这种一行式的 就难看 12/14 14:42
25F：→ BlueBird5566: 样只要一个回圈就处理完 效能较快 但可读性就很差 12/14 14:42
26F：→ baobomb: 面试看到 if else不加大括号的 都直接先扣分... 整个看起 12/14 14:44
27F：→ baobomb: 来有够丑 12/14 14:44
28F：→ shooter555: 不过这些在convention里面定好就好 12/14 14:45
看起来有大括号是显学?
29F：→ testPtt: 一行分号我倒是不介意 只要a不出错後面都可以无视 12/14 14:48
30F：→ baobomb: 一开始可能还好 但函式在扩展时 逻辑可能会变多 然後一 12/14 14:49
31F：→ baobomb: 旦一开始没有大括号 後面就也不会加 最後就是 if(xxx) a; 12/14 14:49
32F：→ baobomb: b; c;....一直加下去 可读性极差 12/14 14:49
33F：推 s06yji3: if-else 有无大括号影响可以很大 12/14 14:54
34F：→ testPtt: 其实看不爽就看ide的格式化功能几个按键搞定 12/14 14:54
其实我是两种都接受
总不能写错程式的时候跟老板说那个XXX if else格式写不对害我看错
35F：→ shooter555: code就是订定好协议 风格一致比较好看 一下{换行一下 12/14 15:09
36F：→ shooter555: {不换行接後面 不一致就是难看而已 12/14 15:10
37F：嘘 hegemon: 第一个就算是Google 的coding style 都会把他处理掉好吗 12/14 15:23
38F：→ hegemon: ？ 12/14 15:23
39F：→ testPtt: 第一个我是遇过变数集中函式集中宣告强迫正 所以会离很远 12/14 15:27
40F：→ sososlee: 真的很讨厌第一种写法 12/14 15:29
41F：推 TSW: 你可以换个环境，写 ruby 吧 12/14 15:31
42F：→ TSW: Coding Style的讨论我觉得很浪费时间，最近都是丢给特别有意 12/14 15:36
43F：→ TSW: 见的成员，让他们自己去formatter的设定档上面编辑战，再让CI 12/14 15:39
44F：→ TSW: 跑过後，Code review 就快多了。 12/14 15:39
45F：→ testPtt: 大家碰到这个要换行吗? public int Goo { get; set; } 12/14 15:53
我看过getter setter保底六七行的 全换行 好丑
46F：推 jknm0510a: 加括号是习惯吧！以後里面加code才不会生出bug难解 12/14 15:58
47F：→ jknm0510a: 加一下不会花你多少时间空间，减少以後出错debug时间 12/14 15:59
48F：→ acgotaku: 第一个确实应该改。而且 styling check 就跑不过了 12/14 16:16
49F：→ Hsins: 写书写笔记为了避免排版跟篇幅问题可以那样写, 实际上开发 12/14 16:19
50F：→ Hsins: 会尽量避免 12/14 16:19
51F：推 bab7171: 笑死 这不是会写c，就要知道的事吗 12/14 16:31
52F：推 bab7171: 为什麽一定要用大括号 12/14 16:32
53F：→ a12838910: 真假啦 第一种这麽讨人厌哦... 12/14 16:33
54F：嘘 k798976869: 不爽括号不会用蟒蛇吗 12/14 16:37
※ 编辑: brucetu (220.135.153.214 台湾), 12/14/2022 16:41:42
55F：推 somefatguy: 我都用ide把大括号设成背景色 12/14 16:44
56F：→ bheegrl: 写一行的那种coding style应该是前端框架才有机会看到吧 12/14 16:46
57F：推 Jasforwe: 我都看心情有时候第一种有时候第二种给你参考 12/14 16:47
58F：推 sniper2824: 第一种我只有return才会这样写 12/14 16:47
59F：→ choosin: 只是括号缩排讲好就好 根本没那麽重要好吗… 12/14 17:05
60F：嘘 peter98: 大括号一定要加的 不管几行 你不加括号 送review被嘴只 12/14 17:55
61F：→ peter98: 是刚好 12/14 17:55
62F：→ peter98: 单行不加括号是很糟糕的坏习惯 12/14 17:57
63F：推 bill0205: 讨厌不换行+1 而且还不+大括号很烦人 12/14 18:30
64F：推 thuko8652: 挂号是一定要写的 12/14 19:02
65F：→ thuko8652: 不写括号习惯太差 12/14 19:02
66F：推 s0914714: 第一种真的很雷 12/14 20:29
67F：→ testPtt: 1.a=>b+c; 2.a=>{b+c;}哪个好 12/14 20:37
68F：嘘 kokona554: 写个括号很难吗 12/14 20:49
69F：嘘 gs8613789: 讨厌不换行 12/14 21:03
70F：嘘 kurtsgm: 拜托你至少断行 12/14 21:25
if (c)
a=2;
有比 if (c) a=2; 好?
※ 编辑: brucetu (220.135.153.214 台湾), 12/14/2022 21:33:25
71F：推 TAKADO: 第一种写法等同於埋地雷给新人踩 12/14 22:29
72F：→ peter98: 一个55分 一个50分 不要在不及格的东西上争论 乖乖加 12/14 22:36
73F：→ peter98: 括号就是 不然gerrit上肯定有人送你个红色大叉叉 12/14 22:37
74F：→ peter98: 更正 gerrit->code review system 12/14 22:38
75F：→ peter98: 至於左括号要刮在if()後面还是跳一行 拜托你看一下原本 12/14 22:39
76F：→ peter98: 的repo里面怎麽写的 照着写 不要标新立异(而且这是很没 12/14 22:39
77F：→ peter98: 创意的标新立异 没人会appreciate你的点) 12/14 22:40
78F：嘘 Dracarys: 有 12/14 22:58
79F：嘘 anandydy529: 自己的专案写一行没差，多人的专案就是埋坑给别人跳 12/14 23:33
80F：→ anandydy529: 而且 google code style 就跟你说要加大括号了 12/14 23:34
81F：嘘 stero: 老实说 单纯你自己觉得好 12/14 23:50
82F：推 chuegou: 大括号必加 12/14 23:50
83F：→ viper9709: if要加大括号+1 12/15 00:03
84F：推 kyo22222: 加大括号比较好 之前Apple就有个有名bug: goto fail 12/15 00:54
85F：→ kyo22222: 如果有加大括号也能避免 12/15 00:54
86F：嘘 germun: 这种会被骂只能说活该 自以为很简洁= = 12/15 00:55
87F：推 w28103566: 第一种写法其实有人推崇，但还是第二种可读性高 12/15 01:21
88F：→ adsl12367: 第一种写法团队开发不建议这样 12/15 01:31
89F：推 milkdragon: Google Coding Style 在某些状况下还是允许不加大括号 12/15 02:13
92F：→ alan3100: 只有说历史原因在特定情况下可省 但没建议你省略 12/15 02:41
93F：推 del680202: 记得之前一个很有名的安全性漏洞 就是没加大括号造成的 12/15 05:28
94F：→ del680202: 然後让一堆公司忙着修补 12/15 05:28
95F：→ mmonkeyboyy: Coding style 不过 正常啊 12/15 05:30
96F：→ mmonkeyboyy: 现代自动检查 你这一定被抓啊 12/15 05:31
97F：推 nurockplayer: 我就是不想写大括号才写 Python 12/15 05:52
98F：推 Hsins: 我喜欢大括号，但不排斥 Python:) 12/15 05:54
99F：推 Csongs: coding style 遵守很难吗...争这个干嘛 12/15 08:45
100F：→ timTan: 很多bug 都是没有大括号来的 12/15 10:15
101F：推 ohmylove347: 第一种不就Kotlin 常见写法吗？不奇怪吧 12/15 10:20
102F：→ baobomb: Kotlin那有第一种写法.... 你说的kt写法应该是 val a = i 12/15 13:14
103F：→ baobomb: f(true) xx else xx 12/15 13:14
104F：→ baobomb: 原po第一种是 if(true) a = xx 12/15 13:14
105F：→ baobomb: 就算是kt 比较稳妥的team 也都是写 val a = if(true) { x 12/15 13:14
106F：→ baobomb: x } else { xx } 12/15 13:14
107F：→ baobomb: 你不加大括号 就算是kt 里面逻辑一旦变多 一样是爆炸好 12/15 13:14
108F：→ baobomb: 吗 12/15 13:14
109F：推 ohmylove347: 不加大括号本来就是给单行用的，就是让最精简的写法 12/15 14:25
110F：→ ohmylove347: 能够更精简，多行当然用括号，第一个写法kt是能用的 12/15 14:25
111F：→ ohmylove347: ，而且也常常当三用运算子用 12/15 14:25
112F：→ ohmylove347: var v = if (a) b else c 12/15 14:26
113F：→ ohmylove347: 不写括号就是为了让单行的精简度更高，习惯了也不会 12/15 14:27
114F：→ ohmylove347: 影响阅读甚至更流畅，多行不加括号已经不是设计本意 12/15 14:28
115F：→ ohmylove347: 了，我自己理解是只有单行可以不加 12/15 14:28
116F：嘘 hegemon: 连单行都会被check style 要求要加好吗？ 12/15 15:09
117F：→ brucetu: 因为没有大括号引发bug应该还是写的人的问题 自己眼残加 12/15 15:55
118F：→ brucetu: 上测试不足 12/15 15:55
119F：→ brucetu: 不过规定一律要加以防有人犯错我是可以认同啦 12/15 15:56
120F：→ robber1234: kt style有指明可以单行不括号,不知道大家在激动啥.. 12/15 16:02
121F：→ baobomb: 还是要看Team size啦 如果只是10-20个人维护的中小型专 12/15 17:21
122F：→ baobomb: 案 可能自己定好style 测试严谨就行 但如果是几百人维护 12/15 17:21
123F：→ baobomb: 的超大型专案 不加真的很常被後面的人越写越丑... 毕竟你 12/15 17:21
124F：→ baobomb: 不能保证所有人都跟你一样 看到逻辑扩展时会reformat cod 12/15 17:21
125F：→ baobomb: e 加上括号抽出逻辑 等到你回头看的时候 常常已经面目全 12/15 17:21
126F：→ baobomb: 非 12/15 17:21
127F：→ baobomb: Kt style单行不加没错 但单行指的是你逻辑简单到不行 而 12/15 17:21
128F：→ baobomb: 且确认不可能会扩展 不然基本上还是加了比较安全 12/15 17:21
我举的例子就是简单到不行的例子
至於是否可能扩展 未来没人会知道啊
当然你要说加了一定没事 是没有错
但是程式码行数越多对阅读越不利
129F：→ superpandal: 我也经常第1种写法 第2种写法是很浪费程式码空间的 12/15 18:13
130F：→ superpandal: 而且也并不难懂 只是习不习惯有没有偏见 12/15 18:14
131F：→ superpandal: 至於bug倒是不会 因为本例就是纯粹指派值 如果有多余 12/15 18:15
132F：→ superpandal: 的设置 当然用括号 也不会有人一连串if 12/15 18:15
133F：推 stupid0319: 程度码空间有限？ 12/15 18:16
134F：→ superpandal: 比起这个我还觉得分号比较重要 12/15 18:17
135F：→ superpandal: 当然理论上没上限 但你要好维护 当然要选择当下条件 12/15 18:18
136F：→ superpandal: 下最简洁的写法 12/15 18:18
137F：→ superpandal: boabomb说的还要糟过三元... 12/15 18:21
138F：推 SHANGOYANYI: …这比三元还烂 把作用域包好很难吗 12/15 20:11
139F：嘘 CaptainTeemo: 在某些条件下可以接受三元，但没有大挂号不行 12/15 22:06
140F：推 baobomb: 楼上... Kotlin的if是表达式 所以没有ternary operator J 12/15 22:09
141F：→ baobomb: ava的三元 如果纯赋值且逻辑简洁的话没什麽问题 但Kt你要 12/15 22:09
142F：→ baobomb: 赋值一行式就是得 if else 12/15 22:09
143F：→ baobomb: 你if else没有大括号 後面绝对超容易被改烂 尤其是Kotlin 12/15 22:11
144F：→ baobomb: 这种语法 单干就算了 几百人写的repo你不加 真的很容易被 12/15 22:11
145F：→ baobomb: 新人搞烂 12/15 22:11
怕新人搞烂老手要收尾所以乾脆全加这个心情我理解
但要论对错的话 还是把code改烂的人的错吧
後手的人加了几行code 结果忘了用括号包起来 整个逻辑都不对
难道开发都不用测试? 应该会测出逻辑根本不对吧
然後烂掉了再去怪前一手的人没有加括号 这样对吗?
一行扩展成多行的时候 怎麽可能会有人忘记要补括号
所以只是在抱怨帮补括号很麻烦?
146F：推 kurtsgm: 都要2023年了 什麽叫做浪费程式码空间 XDDD 12/15 23:32
147F：→ peter98: 会在意程式码空间多於维护性的 要嘛是在极为limited的资 12/16 00:52
148F：→ peter98: 源(ram, disk)下写程式 要马是每写过百人以上专案 不然 12/16 00:53
149F：→ peter98: 就是程式写得不好 通常是後两者居多就是 12/16 00:53
150F：→ peter98: 没写过* 12/16 00:53
151F：→ peter98: 写节省程式码 该用的是OO技巧 而不是在这方面计较 12/16 00:56
152F：→ peter98: 随便做个refactor 把duplicate code拉到一个函式 节省 12/16 00:57
153F：→ peter98: 的空间至少是三元运算子能节省的好几倍 12/16 00:57
154F：→ peter98: 跟薪水也依样 很多人在讨论好好干IT 年薪150没问题 12/16 01:00
155F：→ peter98: 殊不知猪屎屋的起薪一堆就干掉150了 IT怎麽努力也没用 12/16 01:01
156F：→ peter98: 就跟把if else改成三元运算节省空间依样 没用 太局限 12/16 01:01
都是打工仔是在优越什麽 XDD 我看你应该是没做过大生意吧
才会在意这些有的没的
157F：推 baobomb: 同意楼上.. 程式码空间应该靠的是oo 良好的DI 以及适当 12/16 06:56
158F：→ baobomb: 的refactoring.. 而不是什麽非得要一行. 12/16 06:56
159F：推 icydream: google apple goto fail 12/16 09:03
160F：→ gpctv: 我被第一种写法弄过 12/16 10:05
161F：嘘 stellvia2359: 本来就该加括号，没括号是在哭？ 12/16 10:46
162F：→ stellvia2359: 看到不加括号火都上来 12/16 10:47
163F：嘘 s860134: 扩充 会放陷阱害人 12/16 12:40
164F：→ angusyu: Google的Java style确实有说都要加括号,但Kt style没有. 12/16 12:52
165F：→ angusyu: 反正大家都按自己喜好跟公司传统在吵,guidance没人在乎 12/16 12:54
我也觉得就是喜好而已 只能说Google Java style的喜好是要加
166F：推 mmonkeyboyy: OO现在很多也推行少用...维护起来太烦了 12/16 15:25
167F：→ pig0038: leetcode 很常看到第一种写法, 但是我不会在PROD干这种事 12/16 15:47
168F：→ pig0038: 在 OA 写的时候我会先跟面试官声明 12/16 15:48
169F：→ pig0038: 因为 java 写 leetcode 实在太罗嗦了 12/16 15:49
没错明明LC就很常见
170F：→ superpandal: java本身就是OO 你不写OO也得OO 把相同的功能封装是 12/16 19:11
171F：→ superpandal: 正常人都会做的事情 但用三元的例子本身就是单纯案例 12/16 19:12
172F：→ superpandal: 重点这种简易判断出现不会只有一次 出现的很频繁 省 12/16 19:13
173F：→ superpandal: 下的程式码空间和看长程式码需要的暂时记忆以及如果 12/16 19:15
174F：→ superpandal: 找程式码都是有帮助的 12/16 19:16
175F：→ superpandal: s/如果// 12/16 19:17
我不知道为什麽一直攻击不加大括号是不是为了省字的人
都没有考虑程式码行数膨胀对暂时记忆的影响
176F：→ superpandal: java也并非只有OO 也可以搭配FP 不明白这年头为何开 12/16 19:19
177F：→ superpandal: 口闭口OO以及DI 楼主的例子要扩充加括号就好 本身第1 12/16 19:20
178F：→ superpandal: 种写法也不是什麽不常见的做法 12/16 19:20
179F：→ superpandal: 至於kt如果只能如此那就没办法 有没有过誉嫌疑我不知 12/16 19:30
180F：→ superpandal: 道 但以这例子来说确实糟糕 12/16 19:30
181F：嘘 peter98: 正常人会括号 12/16 21:35
182F：→ peter98: 你应该是没做过甚麽大project 12/16 21:35
183F：→ peter98: 你连括号都不知道要加 才跟你提OO 怕你不知道呀 12/16 21:39
184F：→ superpandal: 有阿 大型专案都很乱 你看一下楼主的例子 括号是否必 12/16 22:10
185F：→ superpandal: 要 要加括号的时候自然会加 12/16 22:11
186F：→ superpandal: 没有人会觉得用第一种写法 如果一样条件要增加程式直 12/16 22:12
187F：→ superpandal: 接放下面会能跑的... 12/16 22:13
我也不懂前面好几个说不加括号後面的人会把code改坏 什麽意思
难道前一手没加 後面把它扩充成多行的人也不加? 这样能动? 听起来很有病
188F：→ superpandal: 查了一下 kt可以不用分号也可以用 但分号很好 12/16 22:15
189F：→ superpandal: 只有shell我才不加分号 因为它同行分割需要'\' 12/16 22:18
190F：→ asadman1523: 要括号 12/17 11:10
191F：→ asadman1523: 不喜欢每次还要去帮你加括号我才能塞其他东西 12/17 11:11
是有多少情况会需要一行改多行
每个可以一行的地方都变三行造成阅读的麻烦
跟真的难得有需要改code的时候补个括号
两者衡量一下
当然你可能觉得行数变多没有什麽麻烦
那就是每个人取舍不同的喜好问题而已
192F：推 Dnight: 不加括号以後需求改了要多加一行你不是还是要括号 12/17 11:52
193F：→ Dnight: 那你为什麽要省那个括号 12/17 11:53
之後加跟现在加有差这麽多吗
一定要一开始就加在那边?
我觉得还是可读性问题
少了括号是真的有这麽难读? 各位眼睛还好吗?
194F：推 michael0728n: Linux kernel style是换行不加括号，看话语权没错XD 12/17 16:16
195F：推 viper9709: 推楼楼上 12/17 17:42
196F：推 ohmylove347: 如果要改再一起加好了不是？精简时最精简不是很好吗 12/18 00:01
197F：→ ohmylove347: ？ 12/18 00:01
我也觉得要改再一起加就好 不知道为什麽都要预设会改
有时候就是真的只需要改个状态 写在同一行搞定 未来改成两行以上的机率非常小
会需要改成两行的时候 可能需求已经大到根本可以拆出另一个service 原本的都砍掉
198F：嘘 s8952889: 不懂少一个括号是有什麽好处？少打一些字？？看了就赌烂 12/18 00:20
好处就是 我看了舒服
就像你觉得都有加大括号看了舒服
199F：推 ohmylove347: 好吧，那就只是很多人看单行很不爽XD 12/18 11:34
目前看到不爽的理由
1.以後扩充还要帮你补括号 不爽
2.後面的人很容易改烂 不爽
还有一些系统guideline就是要加 不然你根本build不过
所以要加就是严格 大团队 有标准 赞
至於有些知名专案没在加的
那个我们先不要管它
※ 编辑: brucetu (220.135.153.214 台湾), 12/18/2022 11:39:00
200F：推 Dnight: 既然你Que我了我只好多回一点了，我刚开始工作的时候也觉 12/18 13:04
201F：→ Dnight: 得怎麽可能有人看不懂，但是工作就是没有最夸张只有更夸张 12/18 13:04
202F：→ Dnight: 你觉得if(XXX) 12/18 13:05
203F：→ Dnight: a=2; 後面改个需求後面人会自己加括号，但是就是 12/18 13:06
204F：→ Dnight: 会有天兵直接在下面加一行b=XXX;你如果有加个括号我相信大 12/18 13:08
205F：→ Dnight: 部分人都知道要加在括号里面，这样就减少这种天兵犯错的机 12/18 13:08
206F：→ Dnight: 会，你可能会觉得那是天兵的问题，可是前辈跟给讲了会有天 12/18 13:09
207F：→ Dnight: 兵这样搞，你有机会减少天兵犯错的时候，除非你很有自信你 12/18 13:09
208F：→ Dnight: 的团队只收菁英觉得不接受垃圾，不然你为什麽要挖洞给人跳 12/18 13:10
209F：推 Dnight: 万一很不幸的哪天你接手的专案发现之前有个天兵干了这件事 12/18 13:14
210F：→ Dnight: 然後你还不知道这个天兵有没有可能在所有没括号的地方干同 12/18 13:15
211F：→ Dnight: 样的事情，你可能就知道什麽是显学，跟你讲有人会看不懂不 12/18 13:16
212F：→ Dnight: 是因为我眼睛有问题看不懂，是我真的看过有人看不懂 12/18 13:16
213F：推 viper9709: 推楼上~Apple的goto fail也是例子 12/19 17:36
214F：嘘 sdwqdwd5: 纯嘘用Leetcode的coding style来比较 12/19 19:53
215F：→ sdwqdwd5: *用Leetcode上看到的 12/19 19:56
216F：推 redseye: 有大括号才是好习惯喔... 12/19 22:46
217F：推 bightt97018: LK 你会被挑 12/20 02:14
218F：嘘 h821231: 单行不括号很丑 大型专案也不好维护 其他有括号突然来一 12/21 01:53
219F：→ h821231: 行没有的还不是阅读困难 12/21 01:53
220F：→ h821231: 这不是为了自己方便 而是为了大家方便 与其等别人眼残改 12/21 01:55
221F：→ h821231: 错再来骂不如先加 12/21 01:55
222F：→ h821231: 也没什麽看不看舒服的问题 单纯减少可能出错的机会 12/21 01:57
223F：→ h821231: 看到你有回论对错什麽的 大家是在共同合作才尽量减少别人 12/21 02:01
224F：→ h821231: 出包 而不是出包後花时间检讨谁错 不会帮你加快进度 12/21 02:01
225F：→ h821231: 除非你预设新人不会眼残 或你们团队不收非菁英 那我没话 12/21 02:02
226F：→ h821231: 说 12/21 02:02
227F：推 AminLA: Apple那个是被merge程式搞的吧 12/22 17:55
228F：推 ma721: 加不是常识吗.... 12/28 13:05
229F：→ siriusu: 我真的没看过有知名专案不用加的 有例子吗 12/31 11:11
230F：推 friends29: 这我一定blame除非原本repo全部都是这种 我就闭嘴 01/06 06:16