blocks|key|131188|text|你说得对，var+c+=+a.b和var+c+=+(a.b+!==+null)+?+a.b+:+null;完全一样|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|131189|我的猜测是，三元运算符中的null应该是除null以外的任何值，如果您愿意，这是一个默认值。|131190|entityMap^0|5|B|H|10|0|D|4|L|4|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|I|$]]

You're right, <code>var c = a.b</code> is exactly the same as <code>var c = (a.b !== null) ? a.b : null;</code>

My guess is the <code>null</code> in the ternary operator was meant to be anything except <code>null</code>, a default value if you will.

blocks|key|2903208|text|不，如果b是一个更新变量的方法，它们不一定总是等于。不过，以这种方式编写代码是一种糟糕的做法|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|2903209|var+log+=+0;
var+a+=+{
++++get+b()+{
++++++++log%2B%2B;
++++++++return+log;
++++}
}

var+c+=+(a.b+!==+null)+?+a.b+:+null;
//+outputs+2
console.log(c);|code-block|syntax|javascript|2903210|var+log+=+0;
var+a+=+{
++++get+b()+{
++++++++log%2B%2B;
++++++++return+log;
++++}
}

var+c+=+a.b;
//+outputs+1
console.log(c);|2903211|entityMap^0|D|C|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|R|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|H|7|S|8|@]|D|@]|E|$I|J]]|$1|M|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|N|$]]

No, they AREN'T NECESSARILY EQUAL always if b is a getter that updates a variable. It's bad practice to code this way though

<pre><code>var log = 0;
var a = {
 get b() {
 log++;
 return log;
 }
}

var c = (a.b !== null) ? a.b : null;
// outputs 2
console.log(c);
</code></pre>



<pre><code>var log = 0;
var a = {
 get b() {
 log++;
 return log;
 }
}

var c = a.b;
// outputs 1
console.log(c);
</code></pre>

blocks|key|2903364|text|这些语句在逻辑上与等价。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|2903365|话虽如此，正如在another+answer中提到的，如果a.b有副作用，这些语句将不会导致相同的程序状态。|CODE|2903366|这一点很明显，如果a.b修改了程序中其他地方的某些内容，则var+c会根据执行这些语句中的哪些语句而具有不同的值，或者更隐蔽。|2903367|重构|2903368|由于重构已经讨论过了，所以我将简要介绍一下。正如上面所说的，直接重构并不是在所有情况下都是安全的。然而，我仍然推荐这样或那样的重构。|2903369|我认为有两种可能的情况：|2903370|2903371|a.b没有副作用，直接重构是safe|ordered-list-item|2903372|a.b有隐藏的副作用。这代表了非常不清楚，令人困惑，甚至是彻头彻尾的错误代码。它应该被重构，以便在声明过程中发生的所有更改对读者来说都是清晰和明显的(希望是直观的，并得到注释的支持)。|2903373|2903374|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/31939610/3745896^0|9|3|0|T|3|8|E|0|0|9|3|T|5|0|0|0|0|0|0|3|0|0|3|0|0^^$0|@$1|2|3|4|5|6|7|15|8|@$9|16|A|17|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|18|8|@$9|19|A|1A|B|H]]|D|@$9|1B|A|1C|1|1D]]|E|$]]|$1|I|3|J|5|6|7|1E|8|@$9|1F|A|1G|B|H]|$9|1H|A|1I|B|H]]|D|@]|E|$]]|$1|K|3|L|5|6|7|1J|8|@]|D|@]|E|$]]|$1|M|3|N|5|6|7|1K|8|@]|D|@]|E|$]]|$1|O|3|P|5|6|7|1L|8|@]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|1M|8|@]|D|@]|E|$]]|$1|R|3|S|5|T|7|1N|8|@$9|1O|A|1P|B|H]]|D|@]|E|$]]|$1|U|3|V|5|T|7|1Q|8|@$9|1R|A|1S|B|H]]|D|@]|E|$]]|$1|W|3|-4|5|6|7|1T|8|@]|D|@]|E|$]]|$1|X|3|-4|5|6|7|1U|8|@]|D|@]|E|$]]]|Y|$Z|$5|10|11|12|E|$13|14]]]]

These statements are logically equivalent.
That being said, and as mentioned in <a href="https://stackoverflow.com/a/31939610/3745896">another answer</a>, if <code>a.b</code> has side effects, the statements will not result in the same program state.
This could be readily obvious in the form of <code>var c</code> having a different value depending on which of these statements are executed, or more hidden, if <code>a.b</code> modifies something elsewhere in the program. 
<h3>Refactoring</h3>
As refactoring has been discussed, I'll touch on it briefly. As the above has hopefully made obvious, directly refactoring would not be safe in all scenarios. However, I would still recommend a refactor of one kind or another.
The two possible situations as I see them are:
<ol>
<li><code>a.b</code> has no side effects, direct refactoring is safe</li>
<li><code>a.b</code> has hidden side effects. This represents very unclear, confusing,
and just downright bad code. It should be refactored so that all
changes happening during the statement are clear and obvious to a
reader (hopefully intuitively so, as well as supported by comments).</li>
</ol>

blocks|key|131298|text|出现这种令人困惑的奇怪语法的原因是，a.b可能是空字符串或未定义的，显然空字符串是有效的输入。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|131299|另外，请注意:+a.b可能是一个函数。|131300|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The reason for that confusingly odd syntax is because a.b might be an empty string OR undefined, and apparently an empty string is valid input.

Also, note: a.b might be a function.

blocks|key|131310|text|正如@potatopeelings已经指出的那样，这两种可能的陈述并不总是等价的，因为一个人可以编写晦涩的代码，这将产生不同的结果。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|131311|但是，如果我看到一个代码，比如|131312|var+c+=+(a.b+!==+null)+?+a.b+:+null;|code-block|syntax|javascript|131313|我将假设代码的意图是|131314|var+c+=+a.b;|131315|因此，我将对其进行更改以使代码更美观。如果我会感到负面的惊讶，也就是说，由于这个变化，代码没有通过测试阶段，那么我会试着找到a.b的作者，并将其归咎于git。|offset|length|style|CODE|131316|因此，我的答案是，这两个语句不是等价的，但在编写良好的代码中应该是等价的。|131317|entityMap^0|0|0|0|0|0|1Q|3|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Y|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|Z|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|10|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|11|8|@$O|12|P|13|Q|R]]|9|@]|A|$]]|$1|S|3|T|5|6|7|14|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|V|$]]

As @potatopeelings already pointed out, the two possible statements are not always equivalent, since one can write obscure code, which will have different results.

However, if I see a code, like

<pre><code>var c = (a.b !== null) ? a.b : null;
</code></pre>

I will assume that the code's intention is

<pre><code>var c = a.b;
</code></pre>

so I will change it to make the code prettier. If I will be negatively surprised, that is, the code does not pass the testing phases due to this change, then I will try to find the author of <code>a.b</code> with git blame.

So, my answer is, that the two statements are not equivalent, but should be equivalent in well-written code.

blocks|key|2691261|text|嗯，实际上甚至不是|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2691262|var+c+=+(a+!==+null)+?+a+:+null;|code-block|syntax|javascript|2691263|保证等同于|2691264|var+c+=+a;|2691265|当全局对象上的getter或ES6代理处理程序解析a时。|offset|length|style|CODE|2691266|因此，例如，这将赋值为c的值0：|2691267|​|2691268|Object.defineProperty(self,+'a',+{+get:+function()+{+return+c+%5E=+1;+}+});
var+c+=+(a+!==+null)+?+a+:+null;
console.log(c);|2691269|2691270|而这会将值1赋给c：|2691271|2691272|Object.defineProperty(self,+'a',+{+get:+function()+{+return+c+%5E=+1;+}+});
var+c+=+a;
console.log(c);|2691273|2691274|entityMap^0|0|0|0|0|P|1|0|B|1|0|0|0|0|8|1|0|0|0|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|16|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|17|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|18|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|19|8|@$M|1A|N|1B|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1C|8|@$M|1D|N|1E|O|P]]|9|@]|A|$]]|$1|S|3|T|5|6|7|1F|8|@]|9|@]|A|$]]|$1|U|3|V|5|D|7|1G|8|@]|9|@]|A|$E|F]]|$1|W|3|T|5|6|7|1H|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1I|8|@$M|1J|N|1K|O|P]]|9|@]|A|$]]|$1|Z|3|T|5|6|7|1L|8|@]|9|@]|A|$]]|$1|10|3|11|5|D|7|1M|8|@]|9|@]|A|$E|F]]|$1|12|3|T|5|6|7|1N|8|@]|9|@]|A|$]]|$1|13|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]]|14|$]]

Well, actually not even

<pre><code>var c = (a !== null) ? a : null;
</code></pre>

is guaranteed to be equivalent to

<pre><code>var c = a;
</code></pre>

when <code>a</code> is resolved by a getter or an ES6 proxy handler on the global object.

Hence for instance, this assign to <code>c</code> the value 0:

<div class="snippet" data-lang="js" data-hide="false" data-console="true" data-babel="false">
<div class="snippet-code">
<pre class="snippet-code-js lang-js prettyprint-override"><code>Object.defineProperty(self, 'a', { get: function() { return c ^= 1; } });
var c = (a !== null) ? a : null;
console.log(c);</code></pre>
</div>
</div>


while this assigns to <code>c</code> the value 1:

<div class="snippet" data-lang="js" data-hide="false" data-console="true" data-babel="false">
<div class="snippet-code">
<pre class="snippet-code-js lang-js prettyprint-override"><code>Object.defineProperty(self, 'a', { get: function() { return c ^= 1; } });
var c = a;
console.log(c);</code></pre>
</div>
</div>

I've found this string in JavaScript code.

<pre><code>var c = (a.b !== null) ? a.b : null;
</code></pre>

This is a shorthand of an if-else statement, however the value null is assigned if it is null. Isn't that ALWAYS equivalent to

<pre><code>var c = a.b
</code></pre>

including all cases - exceptions, null, undefined, etc?

In another words, are these lines (always) equivalent?

<pre><code>var c = (a.b !== null) ? a.b : null;
</code></pre>

-vs-

<pre><code>var c = a.b
</code></pre>

Are these lines of JavaScript code equivalent?

我在JavaScript代码中找到了这个字符串。var c = (a.b !== null) ? a.b : null;这是if-else语句的简写，但是如果值为null，则赋值为null。总是等同于var c = a.b是否包括所有情况-异常、null、未定义等？换句话说，这些行(总是)等价吗？var c = (a....

问这几行JavaScript代码等价吗？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问这几行JavaScript代码等价吗？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问这几行JavaScript代码等价吗？
EN