公正评价，这代码什么水平

废话文学家

明明 3 行就写清楚的事，愣是嗦了十几行，给我整无语了
var isOperate_BangDing = "bangDing".equalsIgnoreCase(operateName);
var isOperate_ShuaXin "shuaXin".equalsIgnoreCase(operateName);
if (isOperate_BangDing || isOperate_ShuaXin)

@Leviathann 精辟

为什么要设两个变量，直接 if ("bangDing".equalsIgnoreCase(operateName) || "shuaXin".equalsIgnoreCase(operateName)) {
}
不行么？

@Aliberter #2 原代码两个变量不会同时为 true ，跟你这个不完全等价，不了解需求哪个是对的不知道

英语不太好，但就这点代码体现不出水平高低，他只是选择了非常 verbose 的表达方式而已。好处是看到这句

if (isOperate_BangDing == true
|| isOperate_ShuaXin == true) {...

的时候很舒服，比挤在一起看起来舒服多了。

变量名风格也看得难受

谁写的，刁他啊

一行变七行，这 KPI ，杠杠的

你实话实说，你们公司，是不是把代码量考虑进绩效里面了

@bugFactory 你那样每次都要算一次 equalsIgnoreCase

看工作量的考评方式。
如果工作量考核是用的代码行数或者代码大小（毕竟一个字符要占用一个字节嘛），那么这个代码就是优秀的。

正经应该：
let operators = ['bangDing','shuaXin'];
if (operators.includes(operateName)) {
当然了，这里边没办法解决大小写的问题，可以再写一个大小写转换的 func

我只吐槽一下 英文和拼音最好不要混着写

不看逻辑光看这变量名，驼峰下划线拼音能把人看傻

没啥问题啊，写的挺清楚的。
单看这几行好像挺嗦，但我觉得后面 isOperate_ShuaXin 跟 isOperate_ShuaXin 还会用到的吧。

对于后来的维护者会非常友好

可能一开始不是这样写的后来需求改来改去就开始摆烂打补丁了

遇到这种问题问自己
1. 是老板不
2. 能正常跑不
3. 能发帖摸鱼不
4. 关机

@bugFactory 一是可读性，二是下边的方法还要用这个变量

linter 都过不了…

@lyy16384 是完全等价的，因为不可能存在 operateName 既等于 bangDing 又等于 shuaXin

@cmdOptionKana sonar 的代码规范里不允许这么写，这么写会报警

精梳！这段代码越看越废话，一般人根本写不出来。

== true 是什么鬼

@JKeita 对 且不说这些吧 姑且可以容忍

@spicecch 我的领导写的 可怕不

@happinessnch 因为这是他写的代码，他现在让我去改，我看着难受，想吐槽

@cpstar
@liangkang1436
@Cu635
这是我领导写的，所以不存在为了涨绩效啥的，他之前根本不会 java ，属于是现学现卖的，之前写 c#的

@V2LIYANG 我就是后来的维护者，我已近吐了

@tbxark 不是 是他一气呵成的

@mlhadoop 哈哈 老哥 精辟

@Aliberter 领导写的，就很好理解了，几乎可以肯定他就是像写伪代码一样，既不考虑语言特性，也不综合考虑上下文，就是想到一句写一句，这样可以写得很舒服，大脑低电量模式半梦游状态就可以写了，舒舒服服写完找属下改成风格良好的代码就行，反正他自己舒服。

有没有可能他是觉得比楼主 2 楼的方法在运行时会可能少一次计算量？

垃圾，建议进厂打螺丝！

一看就不是 IDEA 写的

哦才看见是前端，当我没说

告诉他下划线 underline 和小驼峰 low camel 两种风格最好不要混用，还有最好能用英文单词就不要用中文全拼……

@Aliberter #23 对 我没看清比的是同一个变量，既然领导让你改，你直接重构就行了

@Aliberter #30 哈哈哈，我说我看好一会在想这是啥语言，var 关键字还有 C#换行的风格，小驼峰下划线同时用，结果是 java

变量名 is 开头表明是布尔型，这个感觉是加分项；
驼峰+大小写取决于项目整体命名规则；
用英文还是英文拼音混合看团队约定。

else if 后面没有 else 处理异常情况，或者没有双 false 的处理情况，比如 operateName 既不是 bangDing 又不是 shuaXin 是否需要处理。

因为 operateName 只能有一个确定的值，虽然不一定 bangDing 或 shuaXin ，所以给两个变量赋值的部分应该是可以简化的。

下面 if 判断 true 的情况，可以直接判断变量，不需要再写“== true”。

要不要把两个变量直接省略，然后把两个 equalsIgnoreCase 直接放到最下面 if 条件里，取决于下文是否还会用到这两个 equalsIgnoreCase 结果，当然 if 条件太长可读性也未必好。

又不是不能用 /狗头

@glaucus #38 这是 java ，js 没有 equalsIgnoreCase 方法

#2 小白反正看了几分钟硬是没看懂代码的意思，但是看了楼主的代码 2 秒就明白了意思。

@anonydmer 那也应该是
var isOperate_ShuaXin = isOperate_BangDing ? false : "shuaXin".equalsIgnoreCase(operateName)

非要不考虑上下文只考虑代码行数么？

if (Stream.of("shuaXin", "bangDing").anyMatch(operateName::equalsIgnoreCase)) {}

哦，还要加个 operateName 为空的 guard 语句，两行顶天了。

kpi master

水平很差，看过的代码太少，模仿也不会

只看这 1 几行，我觉得还好吧。最后不用==true 判断，再有就是应该定义个常量进行比较而不该用魔法数。至于变量命名，英文不好没办法啦。

@Aliberter , C#不背这个锅，事实上在 VS 里写 C#，各种 resharper 之类的提示，跟着提示改，好多小毛病都能改掉。

不清楚需求，别乱动屎山，
改完，测试提一个二次引入的 bug ，那就尴尬了

为什么英文和拼音混用，驼峰和下划线混用

你们都没写过 switch...case 吗？

@mara1 啊 对不起 没有黑 c#的意思 上边只是陈述下事情

@Suddoo 在屎山上开发也挺难受的

@Leonard 哈哈 挺逗的吧 我也没这么写过

把变量定义提前摆出来不是很好的习惯吗，楼主的改进版也仅仅是把定义和计算放在了一起而已；相反我觉得把变量类型声明成 boolean 看着更舒服

主要是代码风格有问题

可能按代码量考核绩效吧

@chenmoGnar 卧槽。 你有毒啊。if xx 里面设=true ，多写废话很好玩啊。。

也没啥问题吧。楼里说这是屎山，是没见过烂的项目还是自己写的每一句代码都优美精简犹如标准库？

@chenmoGnar mutable 是可维护性和可读性的大忌
所有的变量声明都应该尽可能做到声明即初始化

真没想过他的文化水平这么低

看了一会儿才反应过来是 绑定 和 刷新。

表达的意思清晰，非常好，接手的人一看就懂

为啥我觉得还行呀
挺清晰的，便于维护，就可以了，也没多出来很多没必要的代码呀

@cpstar
我觉得 operators 列表中如果小于等于三个，完全可以用变量代替，还便于阅读代码。

大于三个可以这样

初学者入门水平

楼主小心你的领导也上 v2

就是格式不大好（对齐不易于阅读），其他的水平非常高！
作者充分考虑到现在内存、CPU 资源冗余，用空间和时间开销，换来了代码理解复杂度和后续可扩展性的大幅提升！
试想如果写成了类似：
if ( "bangDing".equalsIgnoreCase(operateName) || "shuaXin".equalsIgnoreCase(operateName) )
{...

代码文本及其逻辑被压缩后，空间和时间开销是小了，但是如果后续要利用操作名结果，每次都还要忽略大小写比较一次，就得一直抓着这个操作名变量不放，这个变量作用域就可能跨几十上百行。另外，这个变量也可能被其他函数 /方法异步修改，如果后续有些其他改动使用，还可能涉及对这个变量读写互斥操作的考虑，反观这个写法会让该次读写结果固定，后续涉及加锁仅需在这两个布尔变量取值处加锁即可。

总之，这段代码简直大神级别操作，谋虑甚远。

doge

@cpstar 面向行数 KPI 编程。

太嗦，命名太差 。

如果要重复使用 isOperate_BangDing ，可以稍微提高一点执行效率，字符串比较是比较耗时的操作

个人看法，并不排斥先定义变量并初始化之后，根据需求逻辑改变变量值并使用变量，虽然当前看来很繁琐，但是方便修改和维护，哪天 bangding 要改成啥东西，不至于漏掉某处。但是不得不说，这个命名方式，真牙疼

肯定不算好，但是也凑合看吧，起码还是比较清楚的。

很不爽楼主这种提问的方式，代码没有上下文，没有业务背景根本讨论不出来个啥。
这段代码编译之后完全没有啥问题，编译器自己会优化。

kpi 拉满，这段代码我给 9 分，不给 10 分主要怕使人过于骄傲。

这代码还行，至少不到吐槽的标准。
命名和代码结构至少是清晰的，
真恶心的是让人看不懂的代码。

还行，凑活着用吧

@alexsunxl 这确实没必要，可以简化下

@TWorldIsNButThis 是不是简单的逻辑要做到声明即初始化；因为我看 jdk 工具包里面都在方法的开始把后面用到的变量都声明了先，后面才初始化。平时我们自己写业务代码也不会单独起一行声明一个变量，也是跟初始化一起。

别的先不说，我真的不理解把 bool 值和 true/false 比较的人到底在想啥

又不是不能运行

switch(operateName.ToLower()){
case "binding":
case "refresh":
dosomething();
break;
...
}

你来我办公室一趟

看着难受, 整那么多 ifelse 做什么, 三目运算符, includes 用上三行以内搞定. 用变量名注解含义还是要的, 但是这个变量名中英文混用,驼峰下划线混用, 真的挖槽. 这种代码读起来像是实习生的面条代码, 又臭又长, 逻辑稍微多一点就要被淹没在 ifelse 的汪洋里.

这就是自己爽就行，不在乎别人的代码，写起来一点心智负担都没有

当 value 为 bool 型的时候，if(value == true)这种写法相比 if(value)有什么好处吗？

`when{
"bangDing".equalsIgnoreCase(operateName),
"shuaXin".equalsIgnoreCase(operateName)->{

}

}
`

`when{`
`"bangDing".equalsIgnoreCase(operateName),`
`"shuaXin".equalsIgnoreCase(operateName)->{`

`}`

`}`

可能是按行数计费时期留下来的代码。

可能是美团的？要统计代码行数？

团队有 coding style 就拿出来怼他。没有……说个捷豹。

这感觉就是一种"流水账"式的写法，先 XXX 然后 XXX ，在分支不多的情况下，这种写法对后来人的维护，我觉得没啥坏处，甚至不要动脑子，比起动不动在一个 if 判断里面加入 N 个 condition 的精简代码，我更喜欢读这种。

只不过最后这个 if (isOperate_BangDing == true|| isOperate_ShuaXin == true) 有点无脑和随意了。然后这个人的命名也很随意。

我会直接改成中文枚举值

if (OnperationName== '绑定'||OnperationName== '刷新') {

}

还在用 var 是什么屑前端，兼容 ie ？

@DOLLOR 如果是 java 的话，Boolean 可能为 null ，boolean 则不会，有时候懒得区分就直接写明 == true 了

这么写会降低运行效率吗, 如果不会, 就是正常水平

@gps949 赞同，强语言才考虑这些，胶水语言很少看到这些考虑。不过就一段代码看不出什么来。就算是整合别人的，在整体考虑别人思路会花费较多时间

俩拼音，不及格。

能赚钱的代码就是好代码