Javascript 的非典型用途和--运算符
如果我没记错的话,Crockford 的“Javascript:好的部分”,他不赞成使用 ++ 或 -- 运算符,但我也倾向于记得他没有提供特别强大的功能反对他们的论点。
下面是这些运算符的用法,我发现它们有助于使我的代码尽可能简洁,特别是在处理当 0 是第一个可能的有效返回值(以及正整数)时返回 -1 的函数/方法时。我会对 ++ 和/或 -- 的其他非典型用法感兴趣,这些用法有力地支持在有意义时使用这些运算符。
我不认为这是为什么的重复避免 JavaScript 中的递增(“++”)和递减(“--”)运算符?而是它的推论:何时不避免它们,而是利用它们来发挥自己的优势。当然,我可能是错误的,并且可能有一些原因我没有考虑为什么以下内容充满了危险,尽管在我看来很优雅——如果我错过了以下内容的次优内容,我我也想知道
var substrIdx = str.indexOf(substr);
if (++substrIdx) {
doSomething(--substrIdx);
}
If I recall correctly from Crockford's "Javascript: The Good Parts", he is not in favor of using the ++ or -- operators, but I also tend to recall he doesn't provide an especially strong argument against them.
Below is a use of these operators that I've found helpful in keeping my code as concise as possible particularly when dealing with functions/methods that return -1 when 0 is the first possible valid return value (along with positive integers). I'll be interested in other atypical uses of ++ and/or -- that make a strong argument in favor of using these operators when they make sense.
I do not consider this a duplicate of Why avoid increment ("++") and decrement ("--") operators in JavaScript? but rather it's corollary: when to not avoid them, but rather use them to your advantage. Of course I could be mistaken and there could be some reason I'm not thinking of as to why the following is fraught with danger despite seeming to me to be elegant -- if I'm missing something sub-optimal about the following, I'd like to know that too
var substrIdx = str.indexOf(substr);
if (++substrIdx) {
doSomething(--substrIdx);
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
简洁并不等于可读或可维护,优雅是在维护者眼中。您发布的代码对我来说似乎不必要地不透明。
在过去的几十年里,我对那些不那么明显的代码产生了强烈的厌恶,即使明显的方法需要更多的代码。如果不止一个人参与其中,隐式和魔术代码几乎总是难以维护。
具体评论:我不明白为什么你认为你的代码比以下内容更简洁、优雅或可读:
它的效率也有点低,因为你正在执行两个操作和一个比较,而不仅仅是一个比较。此外,您将整数错误地视为布尔值,从维护的角度来看,这几乎总是一个坏主意。
最后,正如下面提到的,你阻碍了 Javascript 最小化,从最后简洁的角度来看,用户唯一关心的是页面加载的速度......
Concise is not the same thing as readable or maintainable, and elegance is in the eye of the maintainer. The code you posted seems unnecessarily opaque to me.
Over the past couple of decades I have developed an intense aversion to code that isn't immediately obvious, even if the obvious method requires a good bit more code. Implicit and magic code is almost always less maintainable if more than one person is in the mix.
A specific comment: I don't see why you consider your code to be more concise, elegant, or readable than:
It's also a tiny bit less efficient because you're performing two operations and a comparison instead of just a comparison. Additionally you're mistreating an integer as a boolean which is almost always a bad idea from a maintenance standpoint.
Finally as mentioned below you're hindering Javascript minimizers, and from a standpoint of conciseness at the end the only thing the user cares about is how quickly the page loads...
它是次优的。它会让人类感到困惑,需要通过浏览器传送更多代码,并且需要解释器在运行时做更多工作。
有人试图弄清楚它是什么,必须推理代码中不同点的
substrIdx
的状态 - “它在这里遵守indexOf
的约定,但是在那里它比indexOf
的约定大 1,并且在if
之后它与substr
没有明确的关系。”。它的长度也比
压缩器压缩的难度要大,因为
substrIdx
不再是单个赋值var
。一个好的缩小器会将后者变成类似的东西
,但很少有人会完成不必要的任务。它们在 闭包编译器下比较得很好:
vs
因为闭包编译器错过了转换
的机会a>=0&&
变为a<0||
但增量和减量仍然更长。It's sub-optimal. It is confusing to humans, requires shipping more code over the browser, and requires the interpreter to do more work at runtime.
Someone trying to figure out what it is, has to reason about the state of
substrIdx
at different points in the code -- "it obeys the contract ofindexOf
here, but there it's one greater than the contract ofindexOf
, and after theif
it doesn't have a clear relationship tosubstr
.".It's also longer than
is harder for minifiers to minify because
substrIdx
is no longer a single assignmentvar
.A good minifier will turn the latter into something like
but fewer will do the job with the unnecessary assignment. They compare pretty well under closure compiler:
vs
because closure compiler misses the opportunity to turn
a>=0&&
intoa<0||
but the increment and decrement is still longer.嗯,这肯定是“非典型”。这也是“聪明”。本着“男孩,我希望我永远不必支持这样编写的代码”的“聪明”精神。
代码应该是可读的。我们花在阅读代码上的时间远多于编写代码的时间。这不是。
Well, that's surely "atypical". It's also "clever". In the "boy, I hope I never have to support code written like that" vein of "clever".
Code should be readable. We spend much more time reading code than writing it. This isn't.
我认为唯一可以接受的情况是增量的结果没有被存储,因此它是预增量还是后增量并不重要,并且不会成为错误的来源。
The only case I consider it acceptable is when the result of the increment is not being stored, therefore it doesn't matter if it's pre or post-increment and won't be a source of bugs.