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

[Aliberter]

var isOperate_BangDing = false;
var isOperate_ShuaXin = false;
if ("bangDing".equalsIgnoreCase(operateName))
{
isOperate_BangDing = true;
}
else if ("shuaXin".equalsIgnoreCase(operateName))
{
isOperate_ShuaXin = true;
}

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

[alexsunxl]

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

[cLoudvSnOw]

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

[TWorldIsNButThis]

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

[gitgabige]

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

[diggzhang]

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

[darknoll]

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

[zooo]

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

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

大于三个可以这样

[potatowish]

初学者入门水平

[killva4624]

楼主小心你的领导也上 v2

[gps949]

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

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

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

doge

[Damn]

@cpstar 面向行数 KPI 编程。

[guanhui07]

太啰嗦，命名太差 。

[yolee599]

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

[whyzp2019]

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

[zhanglintc]

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

[liuzhaowei55]

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

[ytll21]

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

[shyrock]

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

[7gugu]

还行，凑活着用吧

[chenmoGnar]

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