小弟寫java的
以前常常寫三元判斷式
就比如說
String a;
if(con) {
a= "aaa";
} else {
a="bbb";
}
這樣就要佔掉六行
所以我通常都是寫
String a= con ? "aaa" : "bbb";
從五行變成一行
在我看來簡潔又方便
但最近給一個資深前輩code review的時候
他說不要用三元判斷式
因為不好閱讀
他工作那麼久也從來不用三元判斷式的
而且java有很多套件都可以用來取代三元判斷式
所以用三元判斷式真的不好嗎？

大部分情況都會變更難閱讀

不會耶我覺得還好，不要有巢狀連續判斷的話我能接受。

如果短的話算很好讀吧

看情況,如果確定只會是簡單狀態變換就沒差,但如果以後會變成are a2 a3,b1 b2那我甘願一開始就用括號寫

缺點多多

邏輯簡單或是很短的方法裡面用短的三元OK其他地方就有人會看漏有些團隊是避免爭論所以完全禁用，所以不要用最省事

consistency 最重要 如果原本 codebase 就沒有用它就不要用

code style有規定就別用，大家一致

不一樣的東西吧 三元運算有回傳值

判斷單一ok 不要判斷>2個就好

就怕嵌套多層，跟鬼一樣，看那一堆冒號直接中風

佔掉六行真的沒那麼誇張… 不然 IDE 也可以處理

如果有參與開發的任何一個人不懂，那就不要

這種比較簡單的 真的沒甚麼好避免的

要:多:潮:有?多?巢? ;問回傳值為多少

要看實際例子才準

目的是利於閱讀吧 行數根本不是重點

如果只有二元判斷那還好 如果是多重判斷 寧願你寫if else 甚至seitct更為好讀switch

程度不好還學人review 啥小，可憐喔

他的問題

if else 加 log 方便，擴展邏輯也方便ternary 除了少打幾個字以外有啥優點？

你可以用 String a; a = "bbb"; if(con) a = "aaa";這樣只要四行，不過三元還是比較方便啦，不要三元裡面又塞三元就好

遵守團隊規範

現在各種dis同事長官

一層可，多層不要

佔6行沒那麼嚴重，以後隨需求擴充或調整，code亂長更麻煩

if-else裡面只有assign一個變數的話 很ok啊

三元盡量只用一層就好你這個例子沒啥問題，有問題的是像這種a = a > b ? a : b > c ? b : c三元套娃算是很嚴重的bad smell

喜歡if else

行數還好，但長度最好注意

我覺得 if else 人眼閱讀速度較快

考量到未來異動彈性，及閱讀性

看你公司有沒有規定coding style 啊

沒有絕對的對錯 看誰比較大就聽誰的

推Killercat的例子，用太多層就有點討厭了

單純的T/F就算了，但是就是有人會繼續接下去寫。三元判斷裡面再接一個三元判斷，所以建議少用。

如果寫成三元會太長我就會考慮改寫法

不會比較好懂+1

別鬧了,MSDN 一大堆三元運算

真的討厭「？」

if else 一票，除非公司現在和未來都是找高手

有註解傳回什麼就好 基本不會去追內層

不要巢狀還好吧?

容易變得難閱讀，真的覺得很多行用function 包起來

你不會問他推薦怎麼寫再拿上來給大家比較哦

短的很好讀啊，不然就加個註解

用function包起來+1

簡單的情況可以用 不過規定不要用就別用

個人真的建議不要用.但是上班當狗就要聽老闆的

我喜歡用，有時候會 讓程式變得好閱讀

有沒有人看過這樣寫的 var temp = con ? this.a() : this.b(); 看到這種有點不知道該不該給他過

簡單時好用，太複雜不好，但怎樣算太複雜每個人都不一樣

不要巢狀 就可以 之前同事寫過巢狀 傻眼qq

我覺得寫這個都不行的大概也不能接受lambda

Ninja Code?不過公司有Code review與coding style規範還是好事……

兩層就寫啊 寫太多層才會不知道幹嘛 而且應該要包起來

要看多長

不要巢狀讀到這段如果花了一秒以上理解 就要重構

老實說這算基礎吧

看團隊規範啊 有 coding guideline 就照規定走沒規範就先寫個 guideline

私以為，一個東西會存在就是有它的用處，適合的時候就用適合的方法，極端的只用或不用都只是一個對自己有利的借口罷了。

談到 coding style 話語權才是唯一真理

Indeed，只有Lead字輩，才能決定Coding style。

看三元判斷式裡面的內容如果你的條件很長而不是單純的if a=b這種那的確就會難閱讀

你是對的

這怎麼不好閱讀？？

寫法就討論 團隊都能配合就好

尚未看到好的回答

蠻常見到新人會煩惱，像是看到前人的用 if-else if蓋個20幾樓，納悶怎不用 switch-case 重寫這類的問題，經驗上，我認為重構效益大於局部寫法修正，看得懂且性能差異不大的話別糾結太多

通常我是左式ok就不care右式 除非右式內容常常改再分出來

原po 提得狀況，我認為可以使用，但如果是 Stringa = cond1 ? "a" : (cond2？"c" : "d") 這種還是展開來寫比較好

你這個case寫if else的我會叫他改成三元

以可讀性來說，肯定是不行的

多層別用三元，但用if else也不好看，要包function用early return

其實我是覺得是那個資深前輩看不懂，如果一開始是很簡單的兩個簡單條件就還好

出事誰扛責任就聽誰的

對於一層判斷+assign 三元可以一眼就知道要做什麼 熟悉這種寫法後 讀if-else的負擔還比較大一點點

你前輩的理由沒有說服力 以這例子來說並沒有較難讀但如果你團隊裡看code的都像你前輩這樣 那還是別用

如果有商業邏輯，寧願分清楚不要省行數

宗教問題 不會有結論

能力太差的才會看得慢 高手都是這樣寫才快

你是 owner 爽怎麼寫都行，不是那就人在屋簷下，我自己是蠻喜歡三元的

看到很多人連出現三元都不行我還蠻驚訝的 但照團隊規範走也很重要

不用驚訝, 80/20法則 業界不是學校, 也不是在比行數

不用省行數 ~重點是看起來怎麼樣

除非向lamba那種重於流程表達的寫法,不然你一般判斷簡寫沒啥差,判斷太複雜難看,判斷簡單就只是自己看順不順眼

看了很煩@@

這種短短都沒差，最怕是超過兩個螢幕寬度的三元...邏輯都一樣，易讀性差很多，我會選擇易讀性

行數不是重點，重點是整個團隊易讀好維護可擴充今天再來個ccc條件，你怎麼辦？還不是要if else或when

可讀性跟效能才是最大重點 其他都次之

所以他推薦怎寫？ 有很多套件可以取代，可以舉例一下嗎？

跟你前輩溝通看看 簡單易懂的三元沒啥問題

只有一層感覺還好

寫扣本來就是好維護第一

(condition) ? "YES" : "NO" 這種很好用阿 要取代真的是要多好幾行code 看了就阿雜就跟goto很好用 改用if-else就是要多好幾行

我以前也因為這樣常被擋不過其實應該只是為了 整份coding style 統一而已這種被擋還好啦，style 問題都最好解決最難解決的是思緒問題，每個人對pattern 喜好不一樣這種觀念差異造成mr過不了。才最頭痛

公司就是降...你寫的程式要讓不同智商的人能看懂...

題外話，python 的 list comprehension 大家的見解是？

個人2層以內接受。但是2層已經不太好讀了

很多發明就是要1行:list.first(x==1).first(x==2)...拆開來寫感覺就很弱

perl系列的可以忽略這串XD

if else也可以寫成一行啊，呵呵

有規範照規範，沒規範不刁難

變得很難讀很痛苦

三元都看不懂是文組吧==

goto現在c++23有scope_exit可以用啊喔等等這串java

一層可以，多層不要，話說你們是沒有更重要的東西可以review了嗎…

選幾個估狗查東西時看順眼的 blog 爬他們的文章學跟練或者歷年鐵人賽評價高的找有興趣的爬回錯篇 0rz

他大概是覺得未來會變多層

你這case單層賦值蠻適合用的

你這個例子不用三元 之後會有人搞到a變成 null reference

有時候用三元判斷式是為了RAII

省行數可以幹嘛？空白行都拿掉不是更省

寫長一點真的很難看

還好啊 看團隊而已

你這樣很容易就超長 笨方法

三元用習慣很簡潔吧...

真的是宗教問題

老鳥太弱了，叫他做leetcode，leetcode十分常用三元

短的一層可以,多層不要+1

三元很好用，可以用的很漂亮

三元判斷式若把一堆條件寫成超出螢幕的一行，之後也是得拆分問號冒號一行一行來維護。如果遇到那種三四個判斷式用一行三元判斷式實現而且沒有括號的，這種得非常小心，因為後續若要擴充功能很容易出事。當然最精彩的就是把巢狀用一行三元判斷式搞定

單層沒啥問題 蠻常用的 多層三元在debug容易造成困擾該拆的還是要拆

這種小事居然可以這麼熱烈討論

一層可 常用的話會反射動作 秒讀懂多層不要

要是只有一層又沒提前講好就他問題，顆顆

這件事你上級主管說什麼就說什麼 sideproject你自己爽就好*說什麼就是什麼

每間都不同，沒什麼對錯。google或speing程式碼在你們code review會過嗎？

code跑起來沒問題，幫你maintain的人閱讀起來沒問題，那就沒問題。沒有對錯。協同合作不是寫一些自己爽的然後別人痛苦的事情。

字面簡潔 可是腦袋要多轉一圈 = 思緒不簡潔

看規定

除非是團隊共識，不然一般不用

可以用，邏輯簡單的話不影響readability

一人專案,團隊=我決定

拜託去看clean code好嗎

java已經夠囉唆了 一兩層三元還可以 以前我剛入行都被這樣推薦 但是業務邏輯多了就知道無腦if else的壞處 如果是golang我可以接受沒三元 本身就比較簡潔

沒寫過前端語言吧 前端模板一堆這種東西

你現在是在工作，不是自爽

就跟一夜情一樣，講好就好了

糟糕，我很常寫巢狀的三元，不過有換行排版應該還好吧

拆開比較好放中斷點

你前輩就是屬於永遠不會碰 GO/kotlin 的那種人還是塊陶吧我猜你們公司還停留在 java7,用 lambda 他還不馬上罵髒話

工作就是看上頭爽不爽 能不能接受 如果上頭喜歡這樣你不爽也得用 這是雙方面的 但如果這都不能講那也就沒有所謂的溝通 基本上都有一些公司所謂的溝通是這樣很想講這不叫溝通好嗎

說難讀的應該是文盲吧

難讀懂的應該是說這種寫成一行吧 result=a?b?c:d:e?f:g不是說看不懂，但是寫成if else要看懂比較快阿

程式要寫給別人看懂，不是自己

單純 判斷0、1寫一行可能大家比較能接受 不然改起來很麻煩

那表示說難讀懂的連表達都不會啊 那叫多層的難讀懂

不用省行數

不要太長的變數或裡面又有巢狀3元判斷...

最近看Software Engineering at Google 作者就有講G社內部就避免這種使用，因為你的code會被其他team閱讀應該要讓其他人對你的code一目瞭然，炫技不是第一要務

還好吧 python 不用這個我反而看不懂

看你的條件內容是怎樣

有些人為了炫技寫到整個code是很短沒錯但可讀性爆低比長code還難開發團隊開發遇到硬要拿leetcode上面那套炫技手法來寫code的很痛苦有時候多個一兩行就會好讀許多卻硬要為了少那一行把整個code變的很詭異

我覺得不要裝B乖乖寫多行一點，註解多一點詳細一點

我有點好奇巢狀三元可讀性有很差嗎？我常寫沒覺得有閱讀問題？還是你們看到的巢狀三元都用換行縮排來排版？都沒換行縮排來排版

我覺得是習慣問題 code style也是內部講好就好另外能把code寫到人家看不懂也是你的本事

看con 很直觀可以 稍微需要想的就不要 看很快的時候很容易想錯 ex err == null ?

看不懂就請他寫註解

我覺得寫三元沒比較厲害

重點是有沒有辦法讓人比較快看得懂這種簡單情況下的東西，挑人的code style 根本呵呵..真的要強維持，自已寫東西進 code style checker啦

邏輯簡單，三元很好看懂，複雜就不要

花1秒和花3秒還是有差

我也遇到一樣的 資深工程師跟我說太長可讀性低

ternary那麼簡單，居然還可以討論這麼多= =