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

[lilei2023]

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

[hccsoul]

只看代码的话 我以为谁把我挂到 v 站了

[liwenxiao132006]

能有这么多人说出这段代码没问题的，可见 v2 大部分人的水平

[monologue520]

我觉得还好吧,有时候一心想着业务逻辑就偶尔会写出这样的代码.

[kaedea]

HTTP ERROR 429

[akakidz]

建议在 eslint 中把==禁掉，这玩意太恶心了

[brader]

其实这没啥，很正常

[hxysnail]

我来总结一下吧，有人脱裤子放屁，有人说真香，零星几个人捂鼻离开现场……

[DeWjjj]

搜索数据监听类型，我觉得既然有这问题考虑拓展为什么不用枚举。
不过个人认为如果有打包工具，这代码大概率转过去也是正常的。

[gzxworknb]

这就是前端工程师么, 大为震撼

[luoxudongs]

哈哈，代码不评论，我只想知道这是哪一款主题~

[daozun]

先相信，再质疑

[terence4444]

这段代码不是最高水平但是要说“被嘲笑”还不至于。
年轻人写程序总有点在“回字几种写法”上纠结，往往忽视了最重要的架构。

[holyfinger]

初出茅庐和返璞归真的区别

[iblessyou]

说实话，我其实一直不大喜欢太花哨的写法。
但现在（ JAVA ）我已经很久没用 fori 了，
不整个 ->或者 :: ，
感觉就好像低人一等。
有时在其中想加逻辑、打断点弄不了，还怕把人家代码整的太 low 了。
有次干啥来着半天有问题，发现还是 fori 好用。
我自己也喜欢看 if fori 这种。


不过我喜欢的是简单的写法，不是精简的写法；不是繁琐的表述
题里这个，我也不喜欢这种。

[fengpan567]

又不是不能用

[clown007]

我觉得挺好🤣

[go522000]

写得不错啊，连我也看得懂。

[maclanelf134]

如果你写的代码是需要封装为组件或者插件,那你有必要优化为简洁的写法的,精简你的代码量,如果不是,那人家爱咋写咋写,跟你没关系,你觉得不好,你自己写的时候改为你喜欢的写法就行了,没必要拿别人的代码出来鞭尸,写了好几年代码了,总会不自觉的根据业务去考虑代码是否要压缩为最简洁的写法,没准人家就是想着后面万一再进来 N 多个 if else 又没法合并呢! 只要是写了注释的,或者代码让人一眼能看明白的!那就是没毛病!

[dj721xHiAvbL11n0]

少一点歧视，多一些鼓励，尊重他人习惯。大家一起共事，大家好你才能好。

[knva]

为什么不写 php ！

[honggexuan]

magic number 这个问题也得看场景，比如一个点赞功能，就 0 未评价 1 赞 2 踩，非要我去定义一个 enum 去处理这几个状态，我觉得没必要，直接 012 就算了

[watzds]

可扩展性很强，厉害

[phxsuns]

写的挺好，一眼懂。
后面再加其他变量或逻辑，直接加就好了。

[Desiree]

工作中最讨厌就是 Op 这种人

[Anivial]

没有什么大问题，不必被说成🪨山，是能说可以优化，添加 2 代表的涵义注释或者将 2 放入一个可读性强的常量定义，例如 const XX_CONSTANT = 2 ，if (channelType === XX_CONSTANT)。
现在你嘲笑别人，将来说不定别人嘲笑你，历史总是惊人的相似，没必要觉得自己高人一等。

[ljsh093]

@iblessyou #214 for of for in for each 到头来还是觉得 for(;;)最经典最好用

[Tdy95]

罗.jpg
业务代码能跑就行，何必分个技术高低。
同前端从业者，我现在的感想：每天能准时下班，能接触一些新技术比研究茴有几种写法有意思多了

[lingxipaofan]

能看懂的就是好代码

[zengguibo]

看别人的代码，怎么看都有毛病

[uni]

我认为这段代码确实写得不好，但是不是说改成像 33l 那样就好了，33l 和源代码我认为都是可以的

这段代码的问题是用了副作用，副作用的绝对要想尽办法要避免的东西，不然非常难以维护

具体怎么避免，可以看看新版 react 文档的逃生舱那节，里面就说了，绝大部分的 useEffect 的使用都是可以并且应该避免的，然后详细说明了各种情况的代码应该怎么写

[ryd994]

不算好但是可以接受
只要是不损害性能，且不影响可读性的代码，没必要在 review 时死抠

拆开写，之后加 log 加 debug 代码都方便
比如说，有些情况就不适合挂 debugger ，只能靠 log 或者类似功能的变量去记录

我自己是一般不会这样写，但我也不保证自己绝对没写过这样的代码
如果 PR 刚好到附近那就顺手改了，不然为什么要管？

[HowToMakeLove]

当你经历了项目的历史，就会理解这种写法

[hhjswf]

@hu1e #120 这种写法，我们后端老 jqer 也能维护，computed 好多哥们就看不懂了

[caryonyy]

看了评论，v2 果然大神多

[angryfish]

结论：代码挺好！简单易懂
缺陷：用了魔法数字，除了作者，我们都看不懂 2 是啥意思（某些方面来看，这也许是优点？）

[ibinary]

你想说三元就能实现,但没考虑到业务场景. type 不统一怎么办. 最应该改的是 2 这个 magic number. 不要嘲笑别人,那是你还没经历过业务毒打.

[lysS]

@iapplebear 不是三元啊，直接 return channelType==2

[alleluya]

@sockball07 能用就行 什么是常量?

[Biluesgakki]

@Narcissu5 #56 问题在哪？赐教一下 我只会把他写的简单点🤣

[hhjswf]

@afx #189 不知道是不是我太菜，看到你这段代码，我大脑会自动编译成前辈这段代码。少了这一层转化会不会更好

[zcl0621]

我估计这里会用 switch case ... 这种鬼状态 鬼知道产品要加多少种。。。

写后端的时候加状态 遇到 if xxx==1 else 的老代码 想杀人的心都有了

[gogola]

LZ 蠢货

[laduary]

@kaedea 我也遇到这个报错了，换个节点可以加载

[chenrui920614]

没有阅读负担，挺好的

[zhenghuiy]

哈哈，其实只是一个小话题，评论区里的朋友们大可不必那么严肃。

1. 如果 OP 帖子的标题是，这段代码能不能优化？ 那答案肯定是能。声明常量、省略一个 if else 都可以让代码从局部看更优雅。

2. 但为啥很多人不爽 OP 的行为呢？因为它只能说是不够优雅的代码，但绝谈不上是「屎山」代码。OP 这样发帖嘲讽显然是过了 —— 所以不赞同 OP 的朋友并不是觉得代码本身毫无问题，而是觉得 OP 的行为过了。评论区里其实没有正方和反方，反方只是不赞同这种行为。

3. 回头谈谈代码风格：刚入行时，我也会觉得某些精巧的代码结构真酷，甚至有时会想着把一些看似很平的代码改写成更精巧的写法。但过几年回头看，发现 **一眼能看懂且看得舒服的高可读性代码** 才是我们真正需要的 —— 评论区里很多人都有这样的体会，所以不少人猜测 OP 刚工作不久，我默默 +1 。

4. 代码只写一次但可能会被看无数次，当我们去看其他人代码的时候，我们一定懒得去慢慢理解「这一坨精巧的结构最后到底想达到什么目的」，而更期望它的结构是舒服的（该有的空格有、相关的逻辑内聚、一个方法体内部用行间隔不同的逻辑块 等）。

5. 最后用一句话总结：相比于一堆你看不懂的代码，截图中这种小问题真不算啥，当不得这种嘲笑。

[aiqinxuancai]

有枚举型的话应该用枚举型，当然也有可能这块不是他定义的，这代码完全没有到需要挂出来的程度。

[jatsz]

这个代码读着舒服，心智负担也小。真正的差的代码时每个语句都看懂了，组合在一起你就不懂了，并且平稳运行超 10 年，你还不敢动。

可以看看别的任何一个改写，在特定的情况下，其实都没有这么直接，至少你需要确认下，而这个写法，你在阅读的时候甚至不用停下原来的思考。

[jameskongawork]

写的挺好，这种代码换一个初级程序员来维护都不头疼

[oneisall8955]

没啥好吐槽的，又不是看不懂

[JKeita]

这种代码反而更好维护，一些人写的花里胡哨看懂都要看半天。

[dev436]

评价这段代码得根据上下文，考虑到各种情况，可以说这 200 多楼说得都对，任何断章取义的思想不可取。

[iv2ex]

一下而过就好了；
没必要盯着别人缺点放大看；也许前辈有更优秀的地方；

[fiypig]

说真的 我喜欢这样的代码

[fueen]

跟你一起工作的同事真惨，写的代码还要被挂在网上来批判

[werls]

@LeegoYih 理解甘地 ，成为甘地。

[99s]

这样写没问题，后期调试，扩展性都好。你觉得好无非就是改成三元表达式。至于数字改常量问题，看项目复杂度，简单的项目压根没必要还单独整个文件放这些常量。

[XuHuan1025]

闻道有先后术业有专攻 如是而已

[hzzhzzdogee]

求问为什么 key 要写成 'searchData.channelType'呢, 是 vue 特性吗

[stillsilly]

这段代码是烂，但也就一般般的烂，不是很严重

给你们看一段超级无敌烂的，烂到我看到这段代码反手就截图发给领导举报了，领导看到了也说确实很离谱




写这代码的人是一个三十多岁的写了很多年 php 刚转前端两三个月的人。
我是项目的前端 owner ，在这之前我有几次给他提修改意见，他跟我说话的语气 感觉他的态度就是：
这种（奇怪的）写法是对的，我试了测了，功能都正常，这样写没问题，你不会这种（奇怪的）写法是因为你见识少。

太搞笑了
他是真的打心眼里觉得自己水平比我高，还是只是因为面子上过不去所以嘴硬？

[47d7tEUBp521E8fJ]

我反而最喜欢同事写这种代码，我之前有个同事自以为是在项目搞各种代码设计显得自己很牛皮。我们的代码和他一个人的代码风格完全不一样的，只有他自己看得懂，没人愿意接手他写的功能。
PS：而且他代码性能还差的一批，看请求时间还慢了一倍。

[lilei2023]

@stillsilly 你这个也行厉害， 我现在维护的项目了类似的代码一大堆啊，每次默念 “哦弥陀佛”

[lilei2023]

@hzzhzzdogee 监听对象中属性的变化，这应该是 vue2 的规范吧

[oneKnow]

@zhenghuiy #245 有时候开一些库里代码，一连串精巧结构放在一起，光解读意图就很烧脑了

[huangqihong]

@oatw 不是，他想说的是可以直接 return channelType === 2 ；精简代码，这一般在 webstrom 里会提示的

[mercurius]

@stillsilly #259 救命，不要给我看拼音变量名……

[markzyh]

没必要纠结的。猜测 op 是刚工作不久的小年轻。看 2 楼的回复就好了。以后会懂得

[qzsi001]

老实说我挺乐意看这种代码的，除了那个 == 2 。
我不想看别人的代码的时候还要自己算三元，去看这个值是怎么控制的。
简单，明晰就好

另外那个 == 2 也不是不行，如果有注释我会觉得这一段写的挺好

[akira]

魔法数字 2 ，这个没得洗。
代码逻辑一眼看懂，简洁明了，有啥不好的。

[LXGMAX]

我代码咋被放出来了 /doge

[lilei2023]

@LXGMAX 原来是你！😂

[kinge]

这是大神的代码,刚入行的小白不会理解的

[webcape233]

@mercurius 这个拼音还凑合 要是每个后面用汉字注视的化，就是后面 1 - 5 的数字实在是看不下去了！

[shiny]

老妪能解：相传唐朝诗人白居易每作一首诗就念给老年妇女听，不懂就改，力求做到她们能懂。

[Ashore]

我就问你秀不秀？

[wangxin13g]

@Ashore 这个循环里进行 IO 操作和三元运算符也是绝了 XD
虽然可能有偏见但是 php 的屎山代码是真的多

[superedlimited]

@Ashore 你们拍 h 片这样拍不怕饭锅爆炸吗？

[stillsilly]

@mercurius
@webcape233
他可能写 10 年 php 没用过数组这种数据结构

[uiosun]

@iapplebear Golang 表示：喜欢三目、反思三目、拒绝三目

直到我看到了“如何将 500 行 Python 代码用 7 行写出来”后，我也很支持拒绝三目运算符

[lei2j]

比较好理解吧

[chaleaochexist]

可能你只会一种语言
等你在一个项目中要使用三种以上语言的时候. 使用通写法是最优解.

[Varobjs]

刚毕业没被毒打的样子，二百行函数，项目中最多嵌套十层以上的 ifelse 都很多

[guanhui07]

挺好的

[abcbuzhiming]

@ytll21
你们觉得的可读性，可能只是因为读的人水平太差了，导致还需要迁就他们
======
程序员的一大幻觉，就是觉得“我就应该和一堆高水平的人一起工作，不应该迁就低水平开发者”。

实际情况是，编程领域的进步一直以来就是把更多的 [低水平开发者] 拉进开发这个行业，以降低成本。

所以，到底谁才是挡在历史车轮前的螳螂？

[gelilaohuang]

哈哈，直接到了编译器编译的阶段了，所有 js 花里胡哨的东西无非就是 if else 和 for 循环组成的

[sechi]

@stillsilly #259 属于是试用期不到就会被开除的水平了

[James369]

切不可看代码的一时，要看代码的历史

[a90120411]

个人觉得这段代码最大的两个问题是
1 、channelType 判断建议用 === 强制类型判断，减少类型不明确带来的隐患；

2 、这个属性 /函数标识符—“searchData.channelType” 和实际执行的操作不匹配，此外且这种带有特殊符号的标识符只能通过 [".."] 语法访问。

如果改成: toggleSMSByChannelType 或是 setSMSByChannelType 是否更契合一些？

还有一点就是，这个函数中的 this.isSms 在 watch 中没定义啊，是截图之前删掉了一些代码还是？如果不在 watch 中声明，调用时要特别注意 this 的值。

其它三元或者语法糖什么个人觉得的真是小事儿，分场景，有的场景用了更简洁易读，有的场景你用了反而读起来更复杂。代码是给人看的，主要还是易读、可维护为主。

个人观点，仅供参考。

[ispinfx]

get 不到笑点

[x86]

当重构过或维护过老项目，就明白这种好了

[beijinglowb]

写 10 年代码了，33L 那种都是小年轻玩的，稍微上点年纪的根本看不懂。
前端娱乐圈名不虚传，楼主贴的这种就是行业内最规范的写法。
虽然不喜欢 Go 的语法，但希望所有语言都像 Go 一样规范。

[ytmsdy]

我快写了 15 年代码了，觉得这玩意儿没问题啊，挺规范的啊！
把这个改成三元运算，就完美了！？写个 if/else 怎么了？
就 TMD 的一个类型，用魔法数字怎么了？
没事少纠结这些细枝末节的问题！多一些规范的代码，少一些花式语法！

[beijinglowb]

@superedlimited
[img]https://images2.imgbox.com/e3/6d/fNZYLxAE_o.png[/img]

[weeei]

@iapplebear 不用三元，this.isSms = channelType == 2 就行。

[acvvkhalil]

还好吧，有时候业务写烦了会写一些蠢代码， 不过现在不用 ts 写的项目确实难受

[afx]

@hhjswf 要是你也习惯了这种思维，你就觉得前辈的代码很啰嗦。

[toesbieya]

@stillsilly 说实话这种单纯的代码质量问题毛毛雨了，我改这种垃圾已经不会吐了，最怕的还是思路天马行空、以及各种骚操作，我最近碰到的骚东西是 el-dialog 里面写了个 fixed 定位的底部操作栏，居然能正常用

[lululau]

简单易懂分对象是谁，对于白痴一眼看去简单易懂和对于老手简单易懂是两个概念好吗

我记得曾经有老手告诉我 theList.stream().map(MyEntity::getAttr) 不如写成 theList.stream().map(e -> e.getAttr()) 好，因为后者简单易懂 😂

[sunorg]

这是我追求和保持的写法。

[MeMoDiv]

可以看出 v2 很大一部分程序员仍然停留在认为商业成功和技术水平强相关的水平上……

[0914xc]

好吧，那我以后再也不用三元和魔法数字了