得恶补编译原理了， false == isShown 和 isShown == false 的区别

效率上是没有区别的。
写成 false == isShown 是为了在手抖写成 false = isShown 的时候让编译器报个错。
用 isShown == false 手抖变成 isShown = false 的时候找半天都找不到

同意楼上，这个应该不算编译原理的问题。
而是一种编程技巧。

并有任何, 只是防止成 assignment 的人. 似 if...else 要加 braces.

@zx120120 说的没错
不过很久之前似乎看到过一篇文章说不提倡这么写 理由。。忘了-_-
anyway, 反正我大 Python 不需要这么写 Yay

@zx120120
在我大微软的C#面前，这都不是个事。

gcc很久之前的版本就能报警告了

没有区别。
这种写法叫做Yoda Notation，王垠老湿还专门写文章喷过，《Yoda表示法错在哪里》。

没有区别
编译原理总是很旧的= =
现在你能想到的人肉优化方式，编译器都已经自动做了= =

@omegaga

记得王垠老湿还专门撰文喷过i++这种写法

LZ逗

削足适履的东西还能被称为优秀...

这么写感觉更混乱。
总不见得一直手抖，把==打成=，又不是帕金森。
况且会“手抖写错”的也不只有这个，比如php的==和===

如果你一个失误写出了 if(isShown = false)
现在的编译器都会报出个warnning提醒你的

一楼正解

无聊的trick

不管这么写是不是值得喷，至少浏览器里的js编译器还没有支持检查这种错误，所以js里这么写是提倡的咯～

1. 这跟编译原理没关系，这句话编译后也就一个cmp，甚至平台支持情况下，如arm，cmp都没有，只是附庸在汇编指令后的条件码。
2. “很多优秀的blabla” 也是扯淡，事实上如果你看过一些牛逼的开源项目，看看人家的coding convention，一般都会明确说写这种语句的时候都用后面一种。

为了避免手误，和正常思维相逆，不太赞同这种写法

这种避免犯错方法还是很有用的，所以那么多优秀的项目才都用这种方法

比较不喜欢这种写法，感觉太变态了点...

两种写法在机器语言上没有区别。如果你说的是抽象语法树或者三地址码的话，应该只有顺序上的区别。

执行效率完全一样。

相反，我认为优秀的项目都不会用前者。并且根据我的观察，部门内喜欢用前者的都是些半吊子程序员，优秀的都喜欢后者，简单易读，符合自然语言的逻辑和直觉。

早期 x == false 很容易不小心写成 x=false 导致永远为 true

现在编译器会检查不说， ide 也会检查， 各种语言对应的代码质量工具也会检查， 这个规则显得有些落后。

然而，定这中规矩，无非是为了规避低质量代码，用简单规则+惩罚来提高整体代码质量。毕竟人的能力有差别。在没有工具支持的时候， 用一个简单的命令式规则， 更加简单高效，比如工具检查出来的 warning 没修复， 那么判断不合格代码，禁止提交。

所以，首先得开发者愿意关心这些『异常』， 并且敏锐地觉察到代码的质量问题，并且修复这些「warning」。也就是高质量的开发者不需要这类小把戏 ， 他们善于使用工具解决， 而不是人肉。

最后， 你也说了， 是『优秀』的项目。这类项目的开发者不屑于这些写， 大部分人完成的大部分项目是配不上『优秀』这两个字的。

LZ真正需要的是补脑

为什么我见过的绝大多数项目都是后一种写法……是因为我见过的项目都不够优秀么？

写前一种的，Code Review绝对不许过，回家治好病再来上班

这年头早就不需要第一种了吧。。

没见过第一种地说

本来写 false == isShown 就已经没意义了吧…… boolean 比较为啥不直接用 not 啊（not 的话还真的直接生成的（未优化）指令会少点……）

c c++ 这么写，原因主要是这个
int a = 5;
if (a = 6) {
cout<<a;
}

@juicy 王垠老湿的意思是这是编程语言的错，而码农们却用一个更加反直觉的做法来修正，等于错上加错，该怎么解决这个问题呢？用王垠老师的Yin语言吧！（大雾…）

可是现实中总有些东西没办法说抛弃就抛弃，所以这不也是没有办法的办法嘛owo 几乎整本Javascript: the Good Parts都充满了这种trick。要是王垠老湿看到了肯定喷出shit了

这种方法一般用在有等号表达式的C系列语言。这类语言里，赋值表达式也有返回值，因此有可能出现这种 == 写成 = 的bug。

在不存在等号表达式（大部分比较新的语言）里都没有这么写的必要，因为赋值表达式不返回值，因此写错了一定会报错的。

@acros 同意

如果说涉及到编译原理的知识的话，那就是有些现代编译器选项支持这个功能：当发现你在条件判断的地方使用了一个赋值语句时，它会给你一个 warning。

@omegaga 的表述不是太准确，这种做法应该叫 Yoda conditions：

http://en.wikipedia.org/wiki/Yoda_conditions

从代码表意上来看，Yoda conditions 是有问题的：

http://blog.codinghorror.com/new-programming-jargon/

@winiex wiki上写了啊，also called Yoda Notation…

@omegaga 失察了，之前自己一直都是这么叫，抱歉。

为啥要 if ( isShown == false )
直接 if( !isShown ) 不就好了

@air20 有时Yoda Notation 还可能是 if(null == person)

@omegaga
@winiex

In programming jargon, Yoda conditions (also called Yoda notation) is a programming style where the two parts of an expression are reversed from the ...
-------from wiki

就是一种防御性编程技巧吧，无它

随着编译器的改进 上古时代的技巧 已经显得过时了

更可怕的是 抱残守缺的思想 凡是祖上流传下来的 不管对不对 就一定要坚持