推 NCUking: 什麼話語權 這是團隊規範該做的好嗎 12/14 14:10
→ lazarus1121: 第一種寫法正常人看到都會罵吧 12/14 14:24
→ vi000246: 第一種寫法比三元還差.. 12/14 14:25
→ LFimi: 這只是coding style根本沒統一而已吧 12/14 14:28
噓 BlueBird5566: 原來不只我討厭第一種寫法 12/14 14:32
→ BlueBird5566: if(xxx) 12/14 14:33
→ BlueBird5566: a=2; 12/14 14:33
→ BlueBird5566: b=3; 12/14 14:33
→ BlueBird5566: 如果是if(xxx) return、break就算了 上面這種更糟 12/14 14:34
→ qwer338859: 第一種在幹嘛....為啥不直接宣告在if上面要離那麼遠 12/14 14:34
→ BlueBird5566: 還跟別行程式並排在一起 12/14 14:35
推 stupid0319: style很漂亮的糞code,至少對公司說的過去 12/14 14:35
→ alan3100: 第一個太爛了吧 為了縮排而縮排比三元更沒意義 12/14 14:35
→ qwer338859: 這是在講縮排嗎 這個不是講好就好 12/14 14:37
→ alan3100: 縮減行數 12/14 14:38
→ qwer338859: 我們這邊只要有if就強制加大誇號就算是空body也一樣 12/14 14:38
→ BlueBird5566: 有{}還是比較好啦 雖然現在CODE只有一行 未來要加 12/14 14:39
→ alan3100: 如過以google java style來講大夸號是必加不能省 12/14 14:40
→ BlueBird5566: 其他行程式也比較不會出錯 沒{}的寫法真的就裝逼~ 12/14 14:40
→ BlueBird5566: 剛學程式時也喜歡那些寫短的code 好像越短越強 12/14 14:41
→ alan3100: 第一種寫法除非你以後絕對不會改到 不然維護上很常出錯 12/14 14:41
→ BlueBird5566: 但工作久了反而覺得可讀性高的程式重要多了 12/14 14:41
→ BlueBird5566: 之前寫個迴圈 同事還叫我把所有邏輯寫在迴圈裡 說這 12/14 14:42
→ shooter555: 我也討厭if(xxx) a=2;這種一行式的 就難看 12/14 14:42
→ BlueBird5566: 樣只要一個迴圈就處理完 效能較快 但可讀性就很差 12/14 14:42
→ baobomb: 面試看到 if else不加大括號的 都直接先扣分... 整個看起 12/14 14:44
→ baobomb: 來有夠醜 12/14 14:44
→ shooter555: 不過這些在convention裡面定好就好 12/14 14:45
→ testPtt: 一行分號我倒是不介意 只要a不出錯後面都可以無視 12/14 14:48
→ baobomb: 一開始可能還好 但函式在擴展時 邏輯可能會變多 然後一 12/14 14:49
→ baobomb: 旦一開始沒有大括號 後面就也不會加 最後就是 if(xxx) a; 12/14 14:49
→ baobomb: b; c;....一直加下去 可讀性極差 12/14 14:49
推 s06yji3: if-else 有無大括號影響可以很大 12/14 14:54
→ testPtt: 其實看不爽就看ide的格式化功能幾個按鍵搞定 12/14 14:54
→ shooter555: code就是訂定好協議 風格一致比較好看 一下{換行一下 12/14 15:09
→ shooter555: {不換行接後面 不一致就是難看而已 12/14 15:10
噓 hegemon: 第一個就算是Google 的coding style 都會把他處理掉好嗎 12/14 15:23
→ hegemon: ？ 12/14 15:23
→ testPtt: 第一個我是遇過變數集中函式集中宣告強迫正 所以會離很遠 12/14 15:27
→ sososlee: 真的很討厭第一種寫法 12/14 15:29
推 TSW: 你可以換個環境，寫 ruby 吧 12/14 15:31
→ TSW: Coding Style的討論我覺得很浪費時間，最近都是丟給特別有意 12/14 15:36
→ TSW: 見的成員，讓他們自己去formatter的設定檔上面編輯戰，再讓CI 12/14 15:39
→ TSW: 跑過後，Code review 就快多了。 12/14 15:39
→ testPtt: 大家碰到這個要換行嗎? public int Goo { get; set; } 12/14 15:53
推 jknm0510a: 加括號是習慣吧！以後裡面加code才不會生出bug難解 12/14 15:58
→ jknm0510a: 加一下不會花你多少時間空間，減少以後出錯debug時間 12/14 15:59
→ acgotaku: 第一個確實應該改。而且 styling check 就跑不過了 12/14 16:16
→ Hsins: 寫書寫筆記為了避免排版跟篇幅問題可以那樣寫, 實際上開發 12/14 16:19
→ Hsins: 會儘量避免 12/14 16:19
推 bab7171: 笑死 這不是會寫c，就要知道的事嗎 12/14 16:31
推 bab7171: 為什麼一定要用大括號 12/14 16:32
→ a12838910: 真假啦 第一種這麼討人厭哦... 12/14 16:33
噓 k798976869: 不爽括號不會用蟒蛇嗎 12/14 16:37
推 somefatguy: 我都用ide把大括號設成背景色 12/14 16:44
→ bheegrl: 寫一行的那種coding style應該是前端框架才有機會看到吧 12/14 16:46
推 Jasforwe: 我都看心情有時候第一種有時候第二種給你參考 12/14 16:47
推 sniper2824: 第一種我只有return才會這樣寫 12/14 16:47
→ choosin: 只是括號縮排講好就好 根本沒那麼重要好嗎… 12/14 17:05
噓 peter98: 大括號一定要加的 不管幾行 你不加括號 送review被嘴只 12/14 17:55
→ peter98: 是剛好 12/14 17:55
→ peter98: 單行不加括號是很糟糕的壞習慣 12/14 17:57
推 bill0205: 討厭不換行+1 而且還不+大括號很煩人 12/14 18:30
推 thuko8652: 掛號是一定要寫的 12/14 19:02
→ thuko8652: 不寫括號習慣太差 12/14 19:02
推 s0914714: 第一種真的很雷 12/14 20:29
→ testPtt: 1.a=>b+c; 2.a=>{b+c;}哪個好 12/14 20:37
噓 kokona554: 寫個括號很難嗎 12/14 20:49
噓 gs8613789: 討厭不換行 12/14 21:03
噓 kurtsgm: 拜託你至少斷行 12/14 21:25
推 TAKADO: 第一種寫法等同於埋地雷給新人踩 12/14 22:29
→ peter98: 一個55分 一個50分 不要在不及格的東西上爭論 乖乖加 12/14 22:36
→ peter98: 括號就是 不然gerrit上肯定有人送你個紅色大叉叉 12/14 22:37
→ peter98: 更正 gerrit->code review system 12/14 22:38
→ peter98: 至於左括號要刮在if()後面還是跳一行 拜託你看一下原本 12/14 22:39
→ peter98: 的repo裡面怎麼寫的 照著寫 不要標新立異(而且這是很沒 12/14 22:39
→ peter98: 創意的標新立異 沒人會appreciate你的點) 12/14 22:40
噓 Dracarys: 有 12/14 22:58
噓 anandydy529: 自己的專案寫一行沒差，多人的專案就是埋坑給別人跳 12/14 23:33
→ anandydy529: 而且 google code style 就跟你說要加大括號了 12/14 23:34
噓 stero: 老實說 單純你自己覺得好 12/14 23:50
推 chuegou: 大括號必加 12/14 23:50
→ viper9709: if要加大括號+1 12/15 00:03
推 kyo22222: 加大括號比較好 之前Apple就有個有名bug: goto fail 12/15 00:54
→ kyo22222: 如果有加大括號也能避免 12/15 00:54
噓 germun: 這種會被罵只能說活該 自以為很簡潔= = 12/15 00:55
推 w28103566: 第一種寫法其實有人推崇，但還是第二種可讀性高 12/15 01:21
→ adsl12367: 第一種寫法團隊開發不建議這樣 12/15 01:31
推 milkdragon: Google Coding Style 在某些狀況下還是允許不加大括號 12/15 02:13
→ alan3100: 只有說歷史原因在特定情況下可省 但沒建議你省略 12/15 02:41
推 del680202: 記得之前一個很有名的安全性漏洞 就是沒加大括號造成的 12/15 05:28
→ del680202: 然後讓一堆公司忙著修補 12/15 05:28
→ mmonkeyboyy: Coding style 不過 正常啊 12/15 05:30
→ mmonkeyboyy: 現代自動檢查 你這一定被抓啊 12/15 05:31
推 nurockplayer: 我就是不想寫大括號才寫 Python 12/15 05:52
推 Hsins: 我喜歡大括號，但不排斥 Python:) 12/15 05:54
推 Csongs: coding style 遵守很難嗎...爭這個幹嘛 12/15 08:45
→ timTan: 很多bug 都是沒有大括號來的 12/15 10:15
推 ohmylove347: 第一種不就Kotlin 常見寫法嗎？不奇怪吧 12/15 10:20
→ baobomb: Kotlin那有第一種寫法.... 你說的kt寫法應該是 val a = i 12/15 13:14
→ baobomb: f(true) xx else xx 12/15 13:14
→ baobomb: 原po第一種是 if(true) a = xx 12/15 13:14
→ baobomb: 就算是kt 比較穩妥的team 也都是寫 val a = if(true) { x 12/15 13:14
→ baobomb: x } else { xx } 12/15 13:14
→ baobomb: 你不加大括號 就算是kt 裡面邏輯一旦變多 一樣是爆炸好 12/15 13:14
→ baobomb: 嗎 12/15 13:14
推 ohmylove347: 不加大括號本來就是給單行用的，就是讓最精簡的寫法 12/15 14:25
→ ohmylove347: 能夠更精簡，多行當然用括號，第一個寫法kt是能用的 12/15 14:25
→ ohmylove347: ，而且也常常當三用運算子用 12/15 14:25
→ ohmylove347: var v = if (a) b else c 12/15 14:26
→ ohmylove347: 不寫括號就是為了讓單行的精簡度更高，習慣了也不會 12/15 14:27
→ ohmylove347: 影響閱讀甚至更流暢，多行不加括號已經不是設計本意 12/15 14:28
→ ohmylove347: 了，我自己理解是只有單行可以不加 12/15 14:28
噓 hegemon: 連單行都會被check style 要求要加好嗎？ 12/15 15:09
→ brucetu: 因為沒有大括號引發bug應該還是寫的人的問題 自己眼殘加 12/15 15:55
→ brucetu: 上測試不足 12/15 15:55
→ brucetu: 不過規定一律要加以防有人犯錯我是可以認同啦 12/15 15:56
→ robber1234: kt style有指明可以單行不括號,不知道大家在激動啥.. 12/15 16:02
→ baobomb: 還是要看Team size啦 如果只是10-20個人維護的中小型專 12/15 17:21
→ baobomb: 案 可能自己定好style 測試嚴謹就行 但如果是幾百人維護 12/15 17:21
→ baobomb: 的超大型專案 不加真的很常被後面的人越寫越醜... 畢竟你 12/15 17:21
→ baobomb: 不能保證所有人都跟你一樣 看到邏輯擴展時會reformat cod 12/15 17:21
→ baobomb: e 加上括號抽出邏輯 等到你回頭看的時候 常常已經面目全 12/15 17:21
→ baobomb: 非 12/15 17:21
→ baobomb: Kt style單行不加沒錯 但單行指的是你邏輯簡單到不行 而 12/15 17:21
→ baobomb: 且確認不可能會擴展 不然基本上還是加了比較安全 12/15 17:21
→ superpandal: 我也經常第1種寫法 第2種寫法是很浪費程式碼空間的 12/15 18:13
→ superpandal: 而且也並不難懂 只是習不習慣有沒有偏見 12/15 18:14
→ superpandal: 至於bug倒是不會 因為本例就是純粹指派值 如果有多餘 12/15 18:15
→ superpandal: 的設置 當然用括號 也不會有人一連串if 12/15 18:15
推 stupid0319: 程度碼空間有限？ 12/15 18:16
→ superpandal: 比起這個我還覺得分號比較重要 12/15 18:17
→ superpandal: 當然理論上沒上限 但你要好維護 當然要選擇當下條件 12/15 18:18
→ superpandal: 下最簡潔的寫法 12/15 18:18
→ superpandal: boabomb說的還要糟過三元... 12/15 18:21
推 SHANGOYANYI: …這比三元還爛 把作用域包好很難嗎 12/15 20:11
噓 CaptainTeemo: 在某些條件下可以接受三元，但沒有大掛號不行 12/15 22:06
推 baobomb: 樓上... Kotlin的if是表達式 所以沒有ternary operator J 12/15 22:09
→ baobomb: ava的三元 如果純賦值且邏輯簡潔的話沒什麼問題 但Kt你要 12/15 22:09
→ baobomb: 賦值一行式就是得 if else 12/15 22:09
→ baobomb: 你if else沒有大括號 後面絕對超容易被改爛 尤其是Kotlin 12/15 22:11
→ baobomb: 這種語法 單幹就算了 幾百人寫的repo你不加 真的很容易被 12/15 22:11
→ baobomb: 新人搞爛 12/15 22:11
推 kurtsgm: 都要2023年了 什麼叫做浪費程式碼空間 XDDD 12/15 23:32
→ peter98: 會在意程式碼空間多於維護性的 要嘛是在極為limited的資 12/16 00:52
→ peter98: 源(ram, disk)下寫程式 要馬是每寫過百人以上專案 不然 12/16 00:53
→ peter98: 就是程式寫得不好 通常是後兩者居多就是 12/16 00:53
→ peter98: 沒寫過* 12/16 00:53
→ peter98: 寫節省程式碼 該用的是OO技巧 而不是在這方面計較 12/16 00:56
→ peter98: 隨便做個refactor 把duplicate code拉到一個函式 節省 12/16 00:57
→ peter98: 的空間至少是三元運算子能節省的好幾倍 12/16 00:57
→ peter98: 跟薪水也依樣 很多人在討論好好幹IT 年薪150沒問題 12/16 01:00
→ peter98: 殊不知豬屎屋的起薪一堆就幹掉150了 IT怎麼努力也沒用 12/16 01:01
→ peter98: 就跟把if else改成三元運算節省空間依樣 沒用 太侷限 12/16 01:01
推 baobomb: 同意樓上.. 程式碼空間應該靠的是oo 良好的DI 以及適當 12/16 06:56
→ baobomb: 的refactoring.. 而不是什麼非得要一行. 12/16 06:56
推 icydream: google apple goto fail 12/16 09:03
→ gpctv: 我被第一種寫法弄過 12/16 10:05
噓 stellvia2359: 本來就該加括號，沒括號是在哭？ 12/16 10:46
→ stellvia2359: 看到不加括號火都上來 12/16 10:47
噓 s860134: 擴充 會放陷阱害人 12/16 12:40
→ angusyu: Google的Java style確實有說都要加括號,但Kt style沒有. 12/16 12:52
→ angusyu: 反正大家都按自己喜好跟公司傳統在吵,guidance沒人在乎 12/16 12:54
推 mmonkeyboyy: OO現在很多也推行少用...維護起來太煩了 12/16 15:25
→ pig0038: leetcode 很常看到第一種寫法, 但是我不會在PROD幹這種事 12/16 15:47
→ pig0038: 在 OA 寫的時候我會先跟面試官聲明 12/16 15:48
→ pig0038: 因為 java 寫 leetcode 實在太囉嗦了 12/16 15:49
→ superpandal: java本身就是OO 你不寫OO也得OO 把相同的功能封裝是 12/16 19:11
→ superpandal: 正常人都會做的事情 但用三元的例子本身就是單純案例 12/16 19:12
→ superpandal: 重點這種簡易判斷出現不會只有一次 出現的很頻繁 省 12/16 19:13
→ superpandal: 下的程式碼空間和看長程式碼需要的暫時記憶以及如果 12/16 19:15
→ superpandal: 找程式碼都是有幫助的 12/16 19:16
→ superpandal: s/如果// 12/16 19:17
→ superpandal: java也並非只有OO 也可以搭配FP 不明白這年頭為何開 12/16 19:19
→ superpandal: 口閉口OO以及DI 樓主的例子要擴充加括號就好 本身第1 12/16 19:20
→ superpandal: 種寫法也不是什麼不常見的做法 12/16 19:20
→ superpandal: 至於kt如果只能如此那就沒辦法 有沒有過譽嫌疑我不知 12/16 19:30
→ superpandal: 道 但以這例子來說確實糟糕 12/16 19:30
噓 peter98: 正常人會括號 12/16 21:35
→ peter98: 你應該是沒做過甚麼大project 12/16 21:35
→ peter98: 你連括號都不知道要加 才跟你提OO 怕你不知道呀 12/16 21:39
→ superpandal: 有阿 大型專案都很亂 你看一下樓主的例子 括號是否必 12/16 22:10
→ superpandal: 要 要加括號的時候自然會加 12/16 22:11
→ superpandal: 沒有人會覺得用第一種寫法 如果一樣條件要增加程式直 12/16 22:12
→ superpandal: 接放下面會能跑的... 12/16 22:13
→ superpandal: 查了一下 kt可以不用分號也可以用 但分號很好 12/16 22:15
→ superpandal: 只有shell我才不加分號 因為它同行分割需要'\' 12/16 22:18
→ asadman1523: 要括號 12/17 11:10
→ asadman1523: 不喜歡每次還要去幫你加括號我才能塞其他東西 12/17 11:11
推 Dnight: 不加括號以後需求改了要多加一行你不是還是要括號 12/17 11:52
→ Dnight: 那你為什麼要省那個括號 12/17 11:53
推 michael0728n: Linux kernel style是換行不加括號，看話語權沒錯XD 12/17 16:16
推 viper9709: 推樓樓上 12/17 17:42
推 ohmylove347: 如果要改再一起加好了不是？精簡時最精簡不是很好嗎 12/18 00:01
→ ohmylove347: ？ 12/18 00:01
噓 s8952889: 不懂少一個括號是有什麼好處？少打一些字？？看了就賭爛 12/18 00:20
推 ohmylove347: 好吧，那就只是很多人看單行很不爽XD 12/18 11:34
推 Dnight: 既然你Que我了我只好多回一點了，我剛開始工作的時候也覺 12/18 13:04
→ Dnight: 得怎麼可能有人看不懂，但是工作就是沒有最誇張只有更誇張 12/18 13:04
→ Dnight: 你覺得if(XXX) 12/18 13:05
→ Dnight: a=2; 後面改個需求後面人會自己加括號，但是就是 12/18 13:06
→ Dnight: 會有天兵直接在下面加一行b=XXX;你如果有加個括號我相信大 12/18 13:08
→ Dnight: 部分人都知道要加在括號裡面，這樣就減少這種天兵犯錯的機 12/18 13:08
→ Dnight: 會，你可能會覺得那是天兵的問題，可是前輩跟給講了會有天 12/18 13:09
→ Dnight: 兵這樣搞，你有機會減少天兵犯錯的時候，除非你很有自信你 12/18 13:09
→ Dnight: 的團隊只收菁英覺得不接受垃圾，不然你為什麼要挖洞給人跳 12/18 13:10
推 Dnight: 萬一很不幸的哪天你接手的專案發現之前有個天兵幹了這件事 12/18 13:14
→ Dnight: 然後你還不知道這個天兵有沒有可能在所有沒括號的地方幹同 12/18 13:15
→ Dnight: 樣的事情，你可能就知道什麼是顯學，跟你講有人會看不懂不 12/18 13:16
→ Dnight: 是因為我眼睛有問題看不懂，是我真的看過有人看不懂 12/18 13:16
推 viper9709: 推樓上~Apple的goto fail也是例子 12/19 17:36
噓 sdwqdwd5: 純噓用Leetcode的coding style來比較 12/19 19:53
→ sdwqdwd5: *用Leetcode上看到的 12/19 19:56
推 redseye: 有大括號才是好習慣喔... 12/19 22:46
推 bightt97018: LK 你會被挑 12/20 02:14
噓 h821231: 單行不括號很醜 大型專案也不好維護 其他有括號突然來一 12/21 01:53
→ h821231: 行沒有的還不是閱讀困難 12/21 01:53
→ h821231: 這不是為了自己方便 而是為了大家方便 與其等別人眼殘改 12/21 01:55
→ h821231: 錯再來罵不如先加 12/21 01:55
→ h821231: 也沒什麼看不看舒服的問題 單純減少可能出錯的機會 12/21 01:57
→ h821231: 看到你有回論對錯什麼的 大家是在共同合作才盡量減少別人 12/21 02:01
→ h821231: 出包 而不是出包後花時間檢討誰錯 不會幫你加快進度 12/21 02:01
→ h821231: 除非你預設新人不會眼殘 或你們團隊不收非菁英 那我沒話 12/21 02:02
→ h821231: 說 12/21 02:02
推 AminLA: Apple那個是被merge程式搞的吧 12/22 17:55
推 ma721: 加不是常識嗎.... 12/28 13:05
→ siriusu: 我真的沒看過有知名專案不用加的 有例子嗎 12/31 11:11
推 friends29: 這我一定blame除非原本repo全部都是這種 我就閉嘴 01/06 06:16