作者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/m.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