小弟写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那么简单，居然还可以讨论这么多= =