三元不能用 算還好了
我還遇過
a=1;
...
...
if (xxx) a=2;
不能這樣寫 請改成
if (xxx) { //還可以戰一下這個{要不要去下一行
a=2;
}
以免有人沒看到那個一行if後面有assign value
這種事情就是看話語權啦
每個人看code習慣不同

什麼話語權 這是團隊規範該做的好嗎

第一種寫法正常人看到都會罵吧

第一種寫法比三元還差..

這只是coding style根本沒統一而已吧

原來不只我討厭第一種寫法if(xxx)a=2;b=3;如果是if(xxx) return、break就算了 上面這種更糟

第一種在幹嘛....為啥不直接宣告在if上面要離那麼遠

還跟別行程式並排在一起

style很漂亮的糞code,至少對公司說的過去

第一個太爛了吧 為了縮排而縮排比三元更沒意義

這是在講縮排嗎 這個不是講好就好

縮減行數

我們這邊只要有if就強制加大誇號就算是空body也一樣

有{}還是比較好啦 雖然現在CODE只有一行 未來要加

如過以google java style來講大夸號是必加不能省

其他行程式也比較不會出錯 沒{}的寫法真的就裝逼~剛學程式時也喜歡那些寫短的code 好像越短越強

第一種寫法除非你以後絕對不會改到 不然維護上很常出錯

但工作久了反而覺得可讀性高的程式重要多了之前寫個迴圈 同事還叫我把所有邏輯寫在迴圈裡 說這

我也討厭if(xxx) a=2;這種一行式的 就難看

樣只要一個迴圈就處理完 效能較快 但可讀性就很差

面試看到 if else不加大括號的 都直接先扣分... 整個看起來有夠醜

不過這些在convention裡面定好就好

一行分號我倒是不介意 只要a不出錯後面都可以無視

一開始可能還好 但函式在擴展時 邏輯可能會變多 然後一旦一開始沒有大括號 後面就也不會加 最後就是 if(xxx) a;b; c;....一直加下去 可讀性極差

if-else 有無大括號影響可以很大

其實看不爽就看ide的格式化功能幾個按鍵搞定

code就是訂定好協議 風格一致比較好看 一下{換行一下{不換行接後面 不一致就是難看而已

第一個就算是Google 的coding style 都會把他處理掉好嗎？

第一個我是遇過變數集中函式集中宣告強迫正 所以會離很遠

真的很討厭第一種寫法

你可以換個環境，寫 ruby 吧Coding Style的討論我覺得很浪費時間，最近都是丟給特別有意見的成員，讓他們自己去formatter的設定檔上面編輯戰，再讓CI跑過後，Code review 就快多了。

大家碰到這個要換行嗎? public int Goo { get; set; }

加括號是習慣吧！以後裡面加code才不會生出bug難解加一下不會花你多少時間空間，減少以後出錯debug時間

第一個確實應該改。而且 styling check 就跑不過了

寫書寫筆記為了避免排版跟篇幅問題可以那樣寫, 實際上開發會儘量避免

笑死 這不是會寫c，就要知道的事嗎為什麼一定要用大括號

真假啦 第一種這麼討人厭哦...

不爽括號不會用蟒蛇嗎

我都用ide把大括號設成背景色

寫一行的那種coding style應該是前端框架才有機會看到吧

我都看心情有時候第一種有時候第二種給你參考

第一種我只有return才會這樣寫

只是括號縮排講好就好 根本沒那麼重要好嗎…

大括號一定要加的 不管幾行 你不加括號 送review被嘴只是剛好單行不加括號是很糟糕的壞習慣

討厭不換行+1 而且還不+大括號很煩人

掛號是一定要寫的不寫括號習慣太差

第一種真的很雷

1.a=>b+c; 2.a=>{b+c;}哪個好

寫個括號很難嗎

討厭不換行

拜託你至少斷行

第一種寫法等同於埋地雷給新人踩

一個55分 一個50分 不要在不及格的東西上爭論 乖乖加括號就是 不然gerrit上肯定有人送你個紅色大叉叉更正 gerrit->code review system至於左括號要刮在if()後面還是跳一行 拜託你看一下原本的repo裡面怎麼寫的 照著寫 不要標新立異(而且這是很沒創意的標新立異 沒人會appreciate你的點)

有

自己的專案寫一行沒差，多人的專案就是埋坑給別人跳而且 google code style 就跟你說要加大括號了

老實說 單純你自己覺得好

大括號必加

if要加大括號+1

加大括號比較好 之前Apple就有個有名bug: goto fail如果有加大括號也能避免

這種會被罵只能說活該 自以為很簡潔= =

第一種寫法其實有人推崇，但還是第二種可讀性高

第一種寫法團隊開發不建議這樣

Google Coding Style 在某些狀況下還是允許不加大括號https://tinyurl.com/4hz6e9vd

只有說歷史原因在特定情況下可省 但沒建議你省略

記得之前一個很有名的安全性漏洞 就是沒加大括號造成的然後讓一堆公司忙著修補

Coding style 不過 正常啊現代自動檢查 你這一定被抓啊

我就是不想寫大括號才寫 Python

我喜歡大括號，但不排斥 Python:)

coding style 遵守很難嗎...爭這個幹嘛

很多bug 都是沒有大括號來的

第一種不就Kotlin 常見寫法嗎？不奇怪吧

Kotlin那有第一種寫法.... 你說的kt寫法應該是 val a = if(true) xx else xx原po第一種是 if(true) a = xx就算是kt 比較穩妥的team 也都是寫 val a = if(true) { xx } else { xx }你不加大括號 就算是kt 裡面邏輯一旦變多 一樣是爆炸好嗎

不加大括號本來就是給單行用的，就是讓最精簡的寫法能夠更精簡，多行當然用括號，第一個寫法kt是能用的，而且也常常當三用運算子用var v = if (a) b else c不寫括號就是為了讓單行的精簡度更高，習慣了也不會影響閱讀甚至更流暢，多行不加括號已經不是設計本意了，我自己理解是只有單行可以不加

連單行都會被check style 要求要加好嗎？

因為沒有大括號引發bug應該還是寫的人的問題 自己眼殘加上測試不足不過規定一律要加以防有人犯錯我是可以認同啦

kt style有指明可以單行不括號,不知道大家在激動啥..

還是要看Team size啦 如果只是10-20個人維護的中小型專案 可能自己定好style 測試嚴謹就行 但如果是幾百人維護的超大型專案 不加真的很常被後面的人越寫越醜... 畢竟你不能保證所有人都跟你一樣 看到邏輯擴展時會reformat code 加上括號抽出邏輯 等到你回頭看的時候 常常已經面目全非Kt style單行不加沒錯 但單行指的是你邏輯簡單到不行 而且確認不可能會擴展 不然基本上還是加了比較安全

我也經常第1種寫法 第2種寫法是很浪費程式碼空間的而且也並不難懂 只是習不習慣有沒有偏見

程度碼空間有限？

比起這個我還覺得分號比較重要當然理論上沒上限 但你要好維護 當然要選擇當下條件下最簡潔的寫法boabomb說的還要糟過三元...

…這比三元還爛 把作用域包好很難嗎

在某些條件下可以接受三元，但沒有大掛號不行

樓上... Kotlin的if是表達式 所以沒有ternary operator Java的三元 如果純賦值且邏輯簡潔的話沒什麼問題 但Kt你要賦值一行式就是得 if else你if else沒有大括號 後面絕對超容易被改爛 尤其是Kotlin這種語法 單幹就算了 幾百人寫的repo你不加 真的很容易被新人搞爛

都要2023年了 什麼叫做浪費程式碼空間 XDDD

會在意程式碼空間多於維護性的 要嘛是在極為limited的資源(ram, disk)下寫程式 要馬是每寫過百人以上專案 不然就是程式寫得不好 通常是後兩者居多就是沒寫過*寫節省程式碼 該用的是OO技巧 而不是在這方面計較隨便做個refactor 把duplicate code拉到一個函式 節省的空間至少是三元運算子能節省的好幾倍跟薪水也依樣 很多人在討論好好幹IT 年薪150沒問題殊不知豬屎屋的起薪一堆就幹掉150了 IT怎麼努力也沒用就跟把if else改成三元運算節省空間依樣 沒用 太侷限

同意樓上.. 程式碼空間應該靠的是oo 良好的DI 以及適當的refactoring.. 而不是什麼非得要一行.

google apple goto fail

我被第一種寫法弄過

本來就該加括號，沒括號是在哭？看到不加括號火都上來

擴充 會放陷阱害人

Google的Java style確實有說都要加括號,但Kt style沒有.反正大家都按自己喜好跟公司傳統在吵,guidance沒人在乎

OO現在很多也推行少用...維護起來太煩了

leetcode 很常看到第一種寫法, 但是我不會在PROD幹這種事在 OA 寫的時候我會先跟面試官聲明因為 java 寫 leetcode 實在太囉嗦了

java本身就是OO 你不寫OO也得OO 把相同的功能封裝是正常人都會做的事情 但用三元的例子本身就是單純案例重點這種簡易判斷出現不會只有一次 出現的很頻繁 省下的程式碼空間和看長程式碼需要的暫時記憶以及如果找程式碼都是有幫助的s/如果//java也並非只有OO 也可以搭配FP 不明白這年頭為何開口閉口OO以及DI 樓主的例子要擴充加括號就好 本身第1種寫法也不是什麼不常見的做法至於kt如果只能如此那就沒辦法 有沒有過譽嫌疑我不知道 但以這例子來說確實糟糕

正常人會括號你應該是沒做過甚麼大project你連括號都不知道要加 才跟你提OO 怕你不知道呀

有阿 大型專案都很亂 你看一下樓主的例子 括號是否必要 要加括號的時候自然會加沒有人會覺得用第一種寫法 如果一樣條件要增加程式直接放下面會能跑的...查了一下 kt可以不用分號也可以用 但分號很好只有shell我才不加分號 因為它同行分割需要'\'

要括號不喜歡每次還要去幫你加括號我才能塞其他東西

不加括號以後需求改了要多加一行你不是還是要括號那你為什麼要省那個括號

Linux kernel style是換行不加括號，看話語權沒錯XD

推樓樓上

如果要改再一起加好了不是？精簡時最精簡不是很好嗎？

不懂少一個括號是有什麼好處？少打一些字？？看了就賭爛

好吧，那就只是很多人看單行很不爽XD

既然你Que我了我只好多回一點了，我剛開始工作的時候也覺得怎麼可能有人看不懂，但是工作就是沒有最誇張只有更誇張你覺得if(XXX)a=2; 後面改個需求後面人會自己加括號，但是就是會有天兵直接在下面加一行b=XXX;你如果有加個括號我相信大部分人都知道要加在括號裡面，這樣就減少這種天兵犯錯的機會，你可能會覺得那是天兵的問題，可是前輩跟給講了會有天兵這樣搞，你有機會減少天兵犯錯的時候，除非你很有自信你的團隊只收菁英覺得不接受垃圾，不然你為什麼要挖洞給人跳萬一很不幸的哪天你接手的專案發現之前有個天兵幹了這件事然後你還不知道這個天兵有沒有可能在所有沒括號的地方幹同樣的事情，你可能就知道什麼是顯學，跟你講有人會看不懂不是因為我眼睛有問題看不懂，是我真的看過有人看不懂

推樓上~Apple的goto fail也是例子

純噓用Leetcode的coding style來比較*用Leetcode上看到的

有大括號才是好習慣喔...

LK 你會被挑

單行不括號很醜 大型專案也不好維護 其他有括號突然來一行沒有的還不是閱讀困難這不是為了自己方便 而是為了大家方便 與其等別人眼殘改錯再來罵不如先加也沒什麼看不看舒服的問題 單純減少可能出錯的機會看到你有回論對錯什麼的 大家是在共同合作才盡量減少別人出包 而不是出包後花時間檢討誰錯 不會幫你加快進度除非你預設新人不會眼殘 或你們團隊不收非菁英 那我沒話說

Apple那個是被merge程式搞的吧

加不是常識嗎....

我真的沒看過有知名專案不用加的 有例子嗎

這我一定blame除非原本repo全部都是這種 我就閉嘴