三元不能用 算还好了
我还遇过
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全部都是这种 我就闭嘴