1
zx120120 2015-01-24 17:33:02 +08:00 6
效率上是没有区别的。
写成 false == isShown 是为了在手抖写成 false = isShown 的时候让编译器报个错。 用 isShown == false 手抖变成 isShown = false 的时候找半天都找不到 |
2
recall704 2015-01-24 17:35:23 +08:00
同意楼上,这个应该不算编译原理的问题。
而是一种编程技巧。 |
3
Elethom 2015-01-24 17:35:42 +08:00
并沒有任何區別, 只是防止寫成 assignment 的人為錯誤. 類似 if...else 要加 braces.
|
4
mulog 2015-01-24 17:36:24 +08:00
|
6
zxtasa 2015-01-24 17:47:01 +08:00
gcc很久之前的版本就能报警告了
|
7
omegaga 2015-01-24 17:56:28 +08:00
没有区别。
这种写法叫做Yoda Notation,王垠老湿还专门写文章喷过,《Yoda表示法错在哪里》。 |
8
hahastudio 2015-01-24 17:58:22 +08:00
没有区别
编译原理总是很旧的= = 现在你能想到的人肉优化方式,编译器都已经自动做了= = |
9
Registering OP |
10
gamecreating 2015-01-24 18:03:00 +08:00
LZ逗
|
11
chrishine 2015-01-24 18:26:17 +08:00
削足适履的东西还能被称为优秀...
|
12
xbb7766 2015-01-24 18:49:03 +08:00
这么写感觉更混乱。
总不见得一直手抖,把==打成=,又不是帕金森。 况且会“手抖写错”的也不只有这个,比如php的==和=== |
13
acros 2015-01-24 18:51:19 +08:00
如果你一个失误写出了 if(isShown = false)
现在的编译器都会报出个warnning提醒你的···· |
14
timothyye 2015-01-24 19:07:34 +08:00 via Android
一楼正解
|
15
FrankFang128 2015-01-24 19:15:58 +08:00 via Android
无聊的trick
|
16
juicy 2015-01-24 19:19:20 +08:00
不管这么写是不是值得喷,至少浏览器里的js编译器还没有支持检查这种错误,所以js里这么写是提倡的咯~
|
17
husinhu 2015-01-24 19:25:04 +08:00
1. 这跟编译原理没关系,这句话编译后也就一个cmp,甚至平台支持情况下,如arm,cmp都没有,只是附庸在汇编指令后的条件码。
2. “很多优秀的blabla” 也是扯淡,事实上如果你看过一些牛逼的开源项目,看看人家的coding convention,一般都会明确说写这种语句的时候都用后面一种。 |
18
chuan 2015-01-24 19:25:18 +08:00
为了避免手误,和正常思维相逆,不太赞同这种写法
|
19
BGLL 2015-01-24 19:26:30 +08:00
这种避免犯错方法还是很有用的,所以那么多优秀的项目才都用这种方法
|
20
Xrong 2015-01-24 19:29:27 +08:00
比较不喜欢这种写法,感觉太变态了点...
|
21
cty 2015-01-24 19:37:25 +08:00
两种写法在机器语言上没有区别。如果你说的是抽象语法树或者三地址码的话,应该只有顺序上的区别。
执行效率完全一样。 |
22
kneep 2015-01-24 20:51:18 +08:00 via iPhone
相反,我认为优秀的项目都不会用前者。并且根据我的观察,部门内喜欢用前者的都是些半吊子程序员,优秀的都喜欢后者,简单易读,符合自然语言的逻辑和直觉。
|
23
hitsmaxft 2015-01-24 21:43:49 +08:00
早期 x == false 很容易不小心写成 x=false 导致永远为 true
现在编译器会检查不说, ide 也会检查, 各种语言对应的代码质量工具也会检查, 这个规则显得有些落后。 然而,定这中规矩,无非是为了规避低质量代码,用简单规则+惩罚来提高整体代码质量。毕竟人的能力有差别。在没有工具支持的时候, 用一个简单的命令式规则, 更加简单高效,比如工具检查出来的 warning 没修复, 那么判断不合格代码,禁止提交。 所以,首先得开发者愿意关心这些『异常』, 并且敏锐地觉察到代码的质量问题,并且修复这些「warning」。也就是高质量的开发者不需要这类小把戏 , 他们善于使用工具解决, 而不是人肉。 最后, 你也说了, 是『优秀』的项目。这类项目的开发者不屑于这些写, 大部分人完成的大部分项目是配不上『优秀』这两个字的。 |
24
churchmice 2015-01-24 21:50:13 +08:00 via Android
LZ真正需要的是补脑
|
25
spacewander 2015-01-24 21:52:12 +08:00
为什么我见过的绝大多数项目都是后一种写法……是因为我见过的项目都不够优秀么?
|
26
9hills 2015-01-24 22:03:19 +08:00
写前一种的,Code Review绝对不许过,回家治好病再来上班
|
27
inevermore 2015-01-24 22:11:31 +08:00
这年头早就不需要第一种了吧。。
|
28
Halry 2015-01-24 22:20:05 +08:00 via Android
没见过第一种地说
|
29
bcxx 2015-01-24 22:34:26 +08:00
本来写 false == isShown 就已经没意义了吧…… boolean 比较为啥不直接用 not 啊(not 的话还真的直接生成的(未优化)指令会少点……)
|
30
huangyanan 2015-01-24 23:11:57 +08:00
c c++ 这么写,原因主要是这个
int a = 5; if (a = 6) { cout<<a; } |
31
omegaga 2015-01-25 09:21:54 +08:00 via Android
@juicy 王垠老湿的意思是这是编程语言的错,而码农们却用一个更加反直觉的做法来修正,等于错上加错,该怎么解决这个问题呢?用王垠老师的Yin语言吧!(大雾…)
可是现实中总有些东西没办法说抛弃就抛弃,所以这不也是没有办法的办法嘛owo 几乎整本JavaScript: the Good Parts都充满了这种trick。要是王垠老湿看到了肯定喷出shit了 |
32
ant_sz 2015-01-25 12:21:34 +08:00
这种方法一般用在有等号表达式的C系列语言。这类语言里,赋值表达式也有返回值,因此有可能出现这种 == 写成 = 的bug。
在不存在等号表达式(大部分比较新的语言)里都没有这么写的必要,因为赋值表达式不返回值,因此写错了一定会报错的。 |
34
winiex 2015-01-25 15:52:37 +08:00
如果说涉及到编译原理的知识的话,那就是有些现代编译器选项支持这个功能:当发现你在条件判断的地方使用了一个赋值语句时,它会给你一个 warning。
@omegaga 的表述不是太准确,这种做法应该叫 Yoda conditions: http://en.wikipedia.org/wiki/Yoda_conditions 从代码表意上来看,Yoda conditions 是有问题的: http://blog.codinghorror.com/new-programming-jargon/ |
37
air20 2015-01-26 03:20:12 +08:00
为啥要 if ( isShown == false )
直接 if( !isShown ) 不就好了 |
38
Registering OP @air20 有时Yoda Notation 还可能是 if(null == person)
|
39
Registering OP |
40
pheyer 2015-01-26 11:27:17 +08:00
就是一种防御性编程技巧吧,无它
|
41
robertlyc 2015-01-26 15:04:45 +08:00
随着编译器的改进 上古时代的技巧 已经显得过时了
更可怕的是 抱残守缺的思想 凡是祖上流传下来的 不管对不对 就一定要坚持 |