分享一段我司前辈的代码，哈哈！

[lilei2023]

老哥们啊，要不就此打住吧！看完大家留言，感觉确实不妥！自省！

[BlueBing]

写的蛮好，一眼懂。

[LeegoYih]

嘲讽前辈，理解前辈，成为前辈。

[Moyyyyyyyyyyye]

简单逻辑简单写，还整个设计模式吗

[Jxnujason]

如果 webstorm 估计会提示，还能一键转掉

[751327]

所有这个应该怎么写？

[yazinnnn]

@LeegoYih
超越前辈.exe

[iyiluo]

没毛病，鬼知道 type 有多少种

[iapplebear]

没啥毛病，逻辑清晰，用三元逼格会高点？

[qwertyzzz]

又不是不能跑

[tsohgdivil]

有啥好笑的

[sockball07]

好奇 前端都不定义常量吗 也没注释这个 2 是什么东西

[meteor957]

以前我还会看看，现在感觉好无聊... 可能是我岁数大了

[lowett]

代码配色挺好啊，看着很舒服

[taotaodaddy]

三元倒不至于,无非是
this.isSms = (channelType == 2);
说实话如果贵司考核代码行数,宁愿像你前辈那样写...

[Xbluer]

挺好的。多了几行，把逻辑运算和赋值分开，简单明了。

[Helsing]

有什么问题吗，除了没有把 2 定义为不可变常量

[lilei2023]

主要是想起来自己刚学的时候，也是这样写的，猜测应该是刚入门的前辈的代码

[taotaodaddy]

魔法数字确实应该重构

[vdrapb]

整挺好，一眼就知道他要干嘛

[xujinkai]

说不定是以前有好几个 if else 现在删的就剩这个了 每一段历史代码都有一段故事

[cwWqjBJJRPak]

难道你还想让他用 channelType===2 吗？！

[jsrunner]

自从自己写了烂代码太多了，现在小弟不喷其他人了

[thorneLiu]

@iapplebear 用得着三元？😂😂😂😂

[still97]

@xujinkai 也有可能一开始写完发现只有一行，考虑到代码行数的考核指标，苦思冥想，改成这样了

[gosansam]

应该是删了别的 else 吧

[isno]

真没必要笑话人家，也没必要在这种小技巧上争强好胜！

[lilei2023]

@lowett vscode monokia

[lyxeno]

成为前辈!

[javen73]

绩效按代码行数吗？😂

[ixixi]

并不是几行所谓的不优雅代码 就能看出别人水平

写一堆自认为风骚的代码 对下个人来说可能就是屎山

多写几行没问题

[shyrock]

OP 把自己的版本发出来，让 v2er 对两者打分看看。

[Ricardoo]

其实挺好的。
如果是自己的私有代码，随便使用利用语言特性，一行代码搞定.
但是如果是项目代码，一眼能让人看懂的代码就是好代码，而且这种代码方便在分支中增加逻辑，想想善变的需求，你以为前辈在初学层级，实际人家是懂业务懂代码的=。=！

[angrylid]

那么比较优雅的写法是下面这样吗？
isSms = computed( () => channelType === 2 )

[lilei2023]

嘲笑谈不上，谁不是从 0-1 开始的，只是感慨，项目这么久了也没人加注释，没人优化

[ksco]

楼上都给我看傻了，这都能洗？😨

[Yukiteru]

简单易懂，没毛病。

[lilei2023]

@angrylid 要是我现在写，肯定写成你这样了
@shyrock 看看#33

[miaotaizi]

代码写再好, 跟业务不匹配有什么用?

[Huelse]

硬要说的话也就判等和枚举有问题，而且我记得会被编译成 this.isSms = ...

[erwin985211]

现在公司好多这样的代码 主要搞得一个组件就有 4 、500 行，看着很难受

[iOCZ]

能一眼看懂的都是好代码

[Vegetable]

这个有很多改进的方法，但这种代码并不值得嘲笑。

这个代码足够简单，虽然写的不优雅，但是也没带来什么问题，甚至可以非常简单的改写成 computed 。写多了业务代码就会意识到，庞大的项目中，类似这种缺乏设计的细节肯定会非常多，代码最关键的是可靠而不是漂亮。如果一段不太好的代码并没有带来理解上的困难和性能上的问题，他就是标准的，合格的代码。

[caqiko]

@taotaodaddy #14 这个比 33 楼更直观

[fisherman0459]

@angrylid 只是 watch 变动, 不能 computed 依赖吧

[wulili]

虽然一行代码能搞定
但是这种写法其实更好，不明白 OP 在笑啥。。。。。

[lincanbin]

可能考核代码行数，我这边就是这样，代码都成屎山了。
还在坚持少写没必要代码的人可能只有我了。

[zjw7sky]

虽然一行代码能搞定
但是这种写法其实更好，不明白 OP 在笑啥。。。。。

[zsc8917zsc]

写成#33 楼的好处是什么呢？

[zj9495]

this.isSms = channelType == 2 ? true : false

你怕是没有见过这种写法的 🐶

[ksco]

这段代码暴露出的最大的问题，是贵司根本没有任何实际意义上的 code review 。一个允许将这样的代码提交到主线的项目，我有理由详细其他的地方也是屎山，为了身心健康，快跑吧。

[oatw]

楼主是不是想说用 computed ？

[343]

这么写很好，甚至推荐所有开发这样写。
因为不知道后面产品会增加什么需求，可能在这个判断条件下，还会增加非常多的代码。

[wei2629]

楼主能不能贴个标准答案，我想学习下怎么写。

[loveumozart]

程序员不应该抠这些细节，这种思维方式不好

[MangoCloud]

程序员就是喜欢喷别人的代码，这代码不好吗，小小年纪以为懂一点代码技巧就可以纵横江湖了

[Narcissu5]

评论区居然这么多人没有看出问题在哪儿。。。

[superedlimited]

@iapplebear 这是半前辈

[westoy]

这代码挺好的啊

等增加需求出来一个 chanelType = 3/4/5/6 ， 处理的东西可能不止一个 this.isSms

这段代码只需要根据情况增加块

用三元或者 map 就需要大改了

[evil0harry]

我觉得是删了 else

[cwWqjBJJRPak]

@zsc8917zsc 好处就是传进来一个'2'直接死逼

[Hilong]

如果是我肯定不会写成这样,但是,别人的就随别人去吧

[HENQIGUAI]

你以为人家在第一层，其实人家在第三层

[RobbySSLu]

尊重前辈，因为你终究会成为前辈。

[Marven]

如果你觉得有问题，你给改了就行，发到网上来，意义在哪呢，不明白 OP 在笑啥

[jin7]

简单易懂没毛病

[Xianmua]

https://lkml.org/lkml/2000/8/25/132

[7gugu]

工资就这么多，工期就这么多，能用就行，又不是不能跑，说不定还没开发完，项目就倒闭了

[wu67]

上面说三元的真是没眼看
this.isSms = (channelType === 2)

还有说需求增加 3 4 5 6 的, isSms 这么大个布尔值你硬是当他透明呀...

[murmur]

@ksco 前端简单的 if-else 自动转三元是 babel 完成的啊，而且别人在 true 或者 false 这里可以随时扩展其他逻辑

我认为没毛病

[alanhe421]

这个并没有问题

[shyrock]

@lilei2023 说实话#33 的箭头函数什么的引入了更多的语法约定，且因为这些约定不符合自然语言，反而增加了阅读者的心智负担。
比方一段使用说明，用白话现代文写出来 100 字，精炼成文言文 25 字。但是文言文版本并不能说就是好的。

[incheon]

楼主没博到认同， 有点遗憾

[murmur]

@wu67 我们有的需求是需要判断 null 或者 undefined 的，谁跟你说 isSms 是 boolean

[cwWqjBJJRPak]

@wu67 我发现很多人都没弄清一个等号两个等号三个等号的含义

[GzhiYi]

楼上没说到重点，不过 OP 想说的重点可能也是 if else 应该换为三元运算符。但这里最重要的是没把 channelType 的值设置为常量，如果在 TS 中，应该设置为 enum ，这给接手的人怎么理解 2 是什么意思。

[Smilencer]

简单易懂没毛病
代码炫技都是得啊施啊波

[westoy]

@wu67

万一出现一个 3, 不去动 isSms, 而是让页面强制跳转到实人认证呢?

追加功能都跟原先设计的一致就不会所有项目必然屎山化了

[coolzjy]

工作经验三年内，鉴定完毕。

[dbow]

业务代码是经常要改的， 给未来修改留下方便， 这是基操。

[Anarchy]

不觉得这是烂代码，ChannelType 的隐藏意义就是可能存在多种。设计这个结构是未来这段逻辑需要演变成这个结构，预先写成这样后面加功能的时候一眼就能找到位置在哪里并做修改。关于直接用数字 2 就是犯懒了，有时候逻辑简单并且后续也大概率是自己主导的代码容易这样，这算是不好的习惯吧。

[MuSeCanYang]

简单易懂没毛病

[dudubaba]

以前觉得这种多余，直接等于 channelType === 2 这种多好，但是这个条件下还有其他赋值，代码就得改成 if else 那还不如最早就用这种。

[danhua]

感觉没什么毛病，简单易懂。或者说可以写简单点但是难懂增加不可替代性。

[LaGeNanRen]

我约了个 meeting ，下班你待一下我们聊聊
@lilei2023

[xyjincan]

改个变量名称 this.sms 咋样

[rivercherdeeeeee]

写的没有问题，记住工作和打工二码事

[hideonwhere]

弄不好原本还有别的业务然后删掉了
但是这种也不影响就是了

[kuaner]

不明白 OP 在笑啥

[fresco]

op 刚上班可能

[twofox]

我朋友在的公司，他们的后端提供的接口是中文的
炸裂

[HFX3389]

笑完记得改代码，别只顾着笑

[sl0000]

用 switch 效率高点

[LawlietZ]

你在嘲笑啥呢 我觉得是你年轻了。。。

[liprais]

以前不只有 channelType == 2 这一个条件吧

[Aviciii]

虽然一行代码能搞定
但是这种写法其实更好，不明白 OP 在笑啥。。。。。

[GzhiYi]

多写一些，可能存在的问题：
1. == 符号尽量少用，这会让类型变得模糊难定，尽可能用全等。
2. channelType 应该使用常量替代，让 2 这个值更具有可读性（这个重要）。

至于楼上说了那么多的拿三元运算符替换，我觉得是不应该的。强行将逻辑 if else 变更为三元运算符，是个坏主意。

再看这个是 vue 的 watch ，除开 channelType 不一定为 2 之外，还可能在后续判断 channelType 后做一些其余的在 channelType 变更后的逻辑。

所以我的看法是，尽管有优化，但写法 if else 没毛病。

[lilei2023]

刚才在捋 n 个前辈的代码，还是继续堆💩山把，跑起来就行，不管那么多了

[fao931013]

可以改 但没有必要

[newmlp]

简单易懂

[finab]

菜鸟程序员会这样写
中等程序员会直接赋值
经验丰富的程序员会回到这种写法，这样是理解成本最低阅读障碍最小甚至不用思考就能看懂的写法

这段代码里魔法数字的问题，比这个要严重的多，最应该改的不是 if else 而是这个