为什么要避免在JavaScript中使用递增(“ ++”)和递减(“-”)运算符?


357

jslint工具提示之一是:

++和-
已知++(递增)和-(递减)运算符会通过鼓励过多的技巧而导致不良代码。在支持病毒和其他安全威胁方面,它们仅次于错误的体系结构。有一个plusplus选项禁止使用这些运算符。

我知道像这样的PHP构造$foo[$bar++]可能很容易导致一次错误的错误,但是我找不到比a while( a < 10 ) do { /* foo */ a++; }或更好的方法来控制循环for (var i=0; i<10; i++) { /* foo */ }

jslint是否突出显示它们,是因为有些相似的语言缺少“ ++”和“ --”语法或以不同的方式处理它,还是有其他理由避免我可能会丢失“ ++”和“ --”?


59
因此,应该使用array [index = index + 1]而不是array [++ index](如果允许前者!)。多么糟糕的呼呼。
劳伦斯·多尔

34
我还没有看到克罗克福德做index = index + 1。我看过他做index + = 1。我认为这是一个合理的选择。而当你想改变步幅来的东西,除了1,它是不错的
Nosredna

124
我个人不是Crockford的忠实拥护者。他似乎认为任何导致其代码错误的内容都是邪恶的。
Paolo Bergantino,2009年

38
在JavaScript中,您应该将每个错误都视为邪恶的,因为没有官方文档,也没有证书提供者,或者您在大学中无法正确学习JS。Crockford和Firebug在JavaScript教学中填补了这些空白。
2010年

40
++不会导致错误。使用++中的“刁钻”的方式可以导致错误,尤其是如果不止一个人维护代码库,但是这不是与运营商的问题,它与程序员的一个问题。我没有在大学学习JS(因为它还不存在),但是那又如何呢?我确实做了C,当然++先有C,但是那也得到了“那又怎样?” 我没有去上大学学习一种特定的语言,而是去学习了可以应用于任何语言的良好编程习惯。
nnnnnn

Answers:


408

我的观点是始终单独使用++和-,如下所示:

i++;
array[i] = foo;

代替

array[++i] = foo;

除此之外,其他任何事情都可能使某些程序员感到困惑,在我看来,这是不值得的。For循环是一个例外,因为增量运算符的使用是惯用的,因此始终是清楚的。


3
是的,那也是我要做的。很难出错,其他人更容易弄清楚您在做什么。
Nosredna,2009年

65
这似乎已成为问题和我的困惑的核心。单独使用,i ++;很清晰。在围绕该基本表达式添加其他代码的那一刻,可读性和清晰度开始受到影响。
artlung

2
同意,但不仅与JavaScript有关
Tobias

5
您没有说要编写C还是C ++。可以争论的是,您应该在C ++中使用前缀增量运算符,以防i以后该变量成为复合类,在这种情况下,您将不必要地创建一个临时对象。我发现后缀运算符在美学上更令人愉悦。
mc0e 2014年

2
我更喜欢1行版本。它提醒了堆栈操作。push是array [++ i] = foo,pop是bar = array [i--]。(但是对于基于0的数组,array [i ++] = foo和bar = array [-i]看起来更好)。另一件事,如果有人在i ++之间添加了额外的代码,我会讨厌它。和array [i] = foo;。
Florian F

257

坦白说,我对这个建议感到困惑。我有一部分想知道这是否与缺乏JavaScript编码器经验(感知的或实际的)有关。

我可以看到有人只是“ hacking”一些示例代码会导致++和-犯一个无辜的错误,但是我不明白为什么有经验的专业人员会避免使用它们。


7
乔恩·B(Jon B)好点了。这就是为什么它令我如此困扰。Crockford是一位职业程序员(数十年身价),数十年来都使用多种语言进行交流,并且从创建之初就基本上使用JavaScript。我认为他的建议不是来自“我是个懒惰且专心的,经验不足的黑客”,这就是为什么我试图了解它的来源。
artlung

14
@artlung也许与“一个懒惰且不专心的经验不足的黑客”有关,这可能会使这段代码变得混乱,并且我不想混淆他。
克里斯·库德莫

9
我完全不同意你的回答。我认为这不是关于“我是否有足够的经验来使用它?”。-但是“清楚吗?” 如果是在for循环中,或者是一个循环,那么就很清楚了-每个人都可以理解而无害。当++在++ x中放置更复杂的表达式时,就会出现问题,因为x与x ++不同,从而导致某些内容不易阅读。克罗克福德的想法不是关于“我能做到吗?” 这是关于“如何避免错误?”
ArtoAle 2012年

1
在个人看来,清晰度对您而言比紧凑性更为重要。这超出了足以理解代码的经验。请参见其他答案,以获取更多麻烦而不是其价值的示例。
Frug 2012年

1
我完全同意。为什么不使用部分语言来妨碍自己?我发现同时使用后增量和前增量以及减量的充分理由。对我来说,这样的行是简洁明了的... if(--imagesLoading === 0)start(); 如果您认为代码不清楚,请使用注释!
xtempore,2012年

69

C中有做类似这样的事情的历史:

while (*a++ = *b++);

复制一个字符串,也许这就是他所指的过度欺骗的根源。

而且总是有一个问题

++i = i++;

要么

i = i++ + ++i;

确实可以。它是在某些语言中定义的,而在其他语言中则无法保证会发生什么。

除了那些示例,我认为没有什么比用于++递增的for循环更惯用的了。在某些情况下,您可以绕开一个foreach循环或一个while循环来检查其他条件。但是扭曲代码以尝试避免使用增量是荒谬的。


104
i = i ++ + ++ i; 使我的眼睛有点受伤-:)
Hugoware

3
我也是。即使它们不是相同的变量,也可以说我有x = a ++ + ++ b; -这种组合立即使x,a和b难以固定在我的脑海中。现在,如果每个都是在不同行上的单独语句,例如-a ++; ++ b; x = a + b; 乍一看会更容易理解。
artlung

10
las,(a ++; b ++; x = a = b)与(a ++ + ++ b)的值不同。
Thomas L Holaday

8
@Marius:x = a+++b-> x = (a++)+b-> x = a + b; a++。分词器贪婪。
卡勒姆·罗杰斯

14
为了提高工作安全性,请删除上一个示例中的空格。
mc0e 2014年

48

如果您阅读JavaScript The Good Parts,您会在C语言中看到Crockford替代i ++的内容循环中是i + = 1(不是i = i + 1)。这很干净而且可读,并且不太可能演变为“棘手”的东西。

克罗克福德作了禁止自动递增和自动的选择在jsLint中将递减设为。您选择是否遵循建议。

我自己的个人规则是不要将任何事情与自动递增或自动递减结合起来。

我从多年的C经验中学到,如果我继续简单地使用它,我不会缓冲区溢出(或数组索引超出范围)。但是我发现,如果我陷入在同一条语句中做其他事情的“过分棘手”的做法,我的确会出现缓冲区溢出。

因此,按照我自己的规则,可以将i ++用作for循环的增量。


关于“ plusplus”选项的要点就是,这是一个选项。根据您的回答和其他答案,我认为我已经意识到++本身或for循环本身并不会造成混淆。第二个将++组合到另一个r语句中的语句在上下文中变得更加难以阅读和理解。
artlung

6
每个人都有缓冲区溢出。甚至是OpenSSH及其开放源代码和多个修订版本
Eric 2009年

11
@Eric回顾您五岁的评论:哦,您是多么正确!
wchargin 2015年

27

在循环中它是无害的,但是在赋值语句中它可能导致意外的结果:

var x = 5;
var y = x++; // y is now 5 and x is 6
var z = ++x; // z is now 7 and x is 7

变量和运算符之间的空格也会导致意外结果:

a = b = c = 1; a ++ ; b -- ; c; console.log('a:', a, 'b:', b, 'c:', c)

最后,意外结果也可能是一个问题:

var foobar = function(i){var count = count || i; return function(){return count++;}}

baz = foobar(1);
baz(); //1
baz(); //2


var alphabeta = function(i){var count = count || i; return function(){return ++count;}}

omega = alphabeta(1);
omega(); //2
omega(); //3

并在换行符之后触发自动分号插入:

var foo = 1, bar = 2, baz = 3, alpha = 4, beta = 5, delta = alpha
++beta; //delta is 4, alpha is 4, beta is 6

增量前/增量后混淆可能会产生难以诊断的一对一错误。幸运的是,它们也完全没有必要。有更好的方法将1加到变量中。

参考文献


13
但是,如果您了解操作员,他们并不是“意外”。这就像没有使用过==,因为你不明白之间的差别=====
greg84

1
究竟。有一个C#问题揭穿了错误的假设。
Paul Sweatte

我认为Crockford的观点是,即使大多数程序员认为自己确实做到了,他们也不是完全“了解操作员”。因此,使用它们存在危险,因为误解的可能性很高。参见@Paul关于错误假设的评论,该评论支持人们普遍误解前缀和后缀运算符实际工作方式的论点。就是说,我承认我喜欢使用它们,但是为了其他目的,我尝试将它们的使用限制为惯用案例(请参阅cdmckay的答案)。
gfullam

您的空白链接似乎已损坏。
罗斯兰

您的“空白”示例有什么棘手的问题?我得到的直接输出a: 2 b: 0 c: 1。在第一个示例(“赋值语句”)中,我也看不到任何奇怪或意外的东西。
肯·威廉姆斯

17

考虑以下代码

    int a[10];
    a[0] = 0;
    a[1] = 0;
    a[2] = 0;
    a[3] = 0;
    int i = 0;
    a[i++] = i++;
    a[i++] = i++;
    a[i++] = i++;

由于i ++得到两次评估,所以输出是(来自vs2005调试器)

    [0] 0   int
    [1] 0   int
    [2] 2   int
    [3] 0   int
    [4] 4   int

现在考虑以下代码:

    int a[10];
    a[0] = 0;
    a[1] = 0;
    a[2] = 0;
    a[3] = 0;
    int i = 0;
    a[++i] = ++i;
    a[++i] = ++i;
    a[++i] = ++i;

请注意,输出是相同的。现在您可能会认为++ i和i ++是相同的。他们不是

    [0] 0   int
    [1] 0   int
    [2] 2   int
    [3] 0   int
    [4] 4   int

最后考虑一下这段代码

    int a[10];
    a[0] = 0;
    a[1] = 0;
    a[2] = 0;
    a[3] = 0;
    int i = 0;
    a[++i] = i++;
    a[++i] = i++;
    a[++i] = i++;

现在的输出是:

    [0] 0   int
    [1] 1   int
    [2] 0   int
    [3] 3   int
    [4] 0   int
    [5] 5   int

因此它们并不相同,将两者混合会导致不太直观的行为。我认为for循环对于++来说还可以,但是当您在同一行或同一指令上有多个++符号时要当心


3
感谢您进行该实验。特别是“外观简单”的代码,但是我的大脑很难很快抓住它。绝对属于“棘手”类别。
artlung

28
我停在第一个例子之后。您说“请考虑以下代码”。不,没人写那个代码。是谁在骗谁,而不是语言建构的白痴。
Sam Harwell

4
您已经证明了两个不同的代码段会产生不同的输出,这证明它不好吗?
尼克

7
结论是“当在同一行或同一指令上有多个++符号时要当心”。我认为您没有看过
Eric

1
“自从i ++得到两次评估以来”-错误!在序列点之间两次修改变量并使用它在C ++中是无效的,并导致不确定的行为。因此,编译器可以执行任何所需的操作。此处显示的结果是编译器实现偶然产生的。
2013年

16

增量和减量运算符的“前”和“后”性质可能会使那些不熟悉它们的人感到困惑。那是他们变得棘手的一种方式。


29
同意;但是,经验丰富的专业人员不应混淆。
内特

1
我认为这类似于避免将所有内容设为静态或全局的指导。作为编程结构,它没有内在的错误,但是无知的过度使用会导致错误的代码。
乔尔·马丁内斯

6
问题不是优秀的程序员是否可以通过逻辑“按自己的方式工作”-理想的代码不需要任何工作即可理解。我认为McWafflestix的观点只是,您不应该编写经过短暂检查就可能导致在两周或两年内添加错误的代码。我知道我一直对向我不完全理解的例程添加代码感到内::)
Mike Mike

1
@Mike:是的,请注意我没有指定操作符对于代码的原始作者还是对以后的维护者而言可能是棘手的。通常,我们尝试假定原始编码人员不使用他们不熟悉/不熟悉的构造(可悲的是,这通常是一个错误的假设);但是,这种熟悉度肯定不会扩展到维护者(并且,如上文附带的注释所示,甚至可能不会扩展到原始作者)。
Paul Sonier 2009年

我尝试编写我的代码供其他程序员阅读,但我尝试编写该代码供初学者阅读。
路加H

16

我认为,“显式总比隐式好。” 因为在某些时候,您可能会对此递增声明感到困惑y+ = x++ + ++y。一个好的程序员总是使他或她的代码更具可读性。


1
x ++或++ y中没有任何隐含内容。
Florian F

1
这种可读的代码是棘手的……我认为您的代码必须有多么简单是一条基线,我们(作为一个社区)必须蓬勃发展,并且能够读取现在不可读的内容,例如单线嵌套ternaries,才能让更多的东西一命呜呼
哈姆扎Ouaghad

14

避免++或-的最重要理由是,运算符同时返回值并引起副作用,这使得对代码进行推理变得更加困难。

为了提高效率,我更喜欢:

  • ++ i的不使用的返回值(没有临时)
  • 我++使用的返回值(无流水线失速)

我是克罗克福德先生的粉丝,但是在这种情况下,我必须不同意。++i是文本解析低于25% i+=1 ,并可以清晰的。


13

我一直在看道格拉斯·克罗克福德(Douglas Crockford)的视频,他对不使用增量和减量的解释是

  1. 过去,它已在其他语言中用于打破数组的界限,并导致各种不良情况。
  2. 更加令人困惑和缺乏经验的JS开发人员不知道它到底在做什么。

首先,JavaScript中的数组是动态调整大小的,因此,如果我错了,请原谅我,不可能突破数组的界限并访问不应在JavaScript中使用此方法访问的数据。

其次,我们应该避免复杂的事情吗?问题肯定不是我们拥有此功能,而是问题在于那里有开发人员声称使用JavaScript但不知道这些运算符如何工作?很简单。value ++,给我当前值,在表达式中加上一个值,即++ value,在给我之前增加值。

如果您只记得上面的内容,像++ + ++ b这样的表达式很容易计算出来。

var a = 1, b = 1, c;
c = a ++ + ++ b;
// c = 1 + 2 = 3; 
// a = 2 (equals two after the expression is finished);
// b = 2;

我想您只需要记住谁必须通读代码,如果您有一支由内而外地了解JS的团队,那么您就不必担心。如果没有,请对其进行注释,然后以不同的方式编写,等等。我认为递增和递减并不是天生就不好,也不是会产生错误,也不是会产生漏洞,根据您的听众而定,其可读性可能较低。

顺便说一句,我认为道格拉斯·克罗克福德(Douglas Crockford)仍然是一个传奇,但我认为他对一个不值得的运营商造成了很多恐慌。

虽然我被证明是错误的...


10

另一个示例,比其他一些示例更简单,只需简单地返回增量值:

function testIncrement1(x) {
    return x++;
}

function testIncrement2(x) {
    return ++x;
}

function testIncrement3(x) {
    return x += 1;
}

console.log(testIncrement1(0)); // 0
console.log(testIncrement2(0)); // 1
console.log(testIncrement3(0)); // 1

如您所见,如果希望此运算符影响结果,则在return语句上不应使用后增/减。但是return不会“捕获”后增/减运算符:

function closureIncrementTest() {
    var x = 0;

    function postIncrementX() {
        return x++;
    }

    var y = postIncrementX();

    console.log(x); // 1
}

您的函数中只有一个函数将x用作参数
Calimero100582

8

我认为程序员应该在使用的语言方面胜任。清楚地使用它;并很好地使用它。我认为他们应该人为地削弱他们使用的语言。我从经验上讲。我曾经在Cobol商店的隔壁工作过,在那里他们不使用ELSE,因为那太复杂了。还原荒谬。


@downvoter令人着迷。您认为程序员不应该精通这种语言吗?您认为他们应该人为削弱语言吗?哪有 这里没有第三选择。
洛恩侯爵,

1
对那个COBOL示例的支持使我更加高兴的是,在我开始编码之前,COBOL几乎全部消亡了
Mark K Cowan

1
@MarkCowan我不明白为什么。我的意思是关于任意限制,而不是语言。轶事并不表明Cobol有任何问题。需要消亡的是那家编程商店,事实确实如此。参观任何大型银行的内幕,您会发现Cobol仍然很健康。
罗恩侯爵

2

正如一些现有答案(令人烦恼的是,我无法对此发表评论)中所提到的那样,问题在于x ++ ++ x会得出不同的值(在增量之前或之后),这并不明显,而且可能非常令人困惑- 如果使用该值。cdmckay非常明智地建议允许使用增量运算符,但是仅以不使用返回值的方式(例如,在其自己的行上)使用。我还将在for循环中包括标准用法(但仅在未使用其返回值的第三条语句中)。我想不出另一个例子。自己被“烧死”后,我会为其他语言推荐相同的指南。

我不同意这种过度限制是由于许多JS程序员缺乏经验的说法。这是“聪明的”程序员的典型写法,而且我敢肯定,它在更传统的语言中以及具有这种语言背景的JS开发人员中更为常见。


1
谢谢回复。您需要信誉值等于或大于50才能发表评论。请参阅:stackoverflow.com/faq
artlung 2011年

1
@artlung:我知道这一点及其背后的原理。我只是说这很烦人:)
Privman附近2011年

2

以我的经验,++ i或i ++从来没有引起混乱,除非是第一次了解运算符的工作原理。对于最高级的for循环和while循环,这是必不可少的,而在任何高中或大学课程中,只要您可以使用运算符就可以教这些语言。我个人觉得做下面的事情要比在单独一行上的++做得更好。

while ( a < 10 ){
    array[a++] = val
}

最后,它是样式首选项,仅此而已,更重要的是,当您在代码中执行此操作时,您将保持一致,以便其他从事同一代码的人可以遵循它们,而不必以不同的方式处理相同的功能。

另外,克罗克福德似乎使用i- = 1,与--i或i--相比,我发现它更难读


2

我的2美分是在两种情况下应避免使用它们:

1)当您有一个在许多行中使用的变量,并且在使用它的第一个语句上(或最后一个,或更糟糕的是,在中间)增加/减少了该变量:

// It's Java, but applies to Js too
vi = list.get ( ++i );
vi1 = list.get ( i + 1 )
out.println ( "Processing values: " + vi + ", " + vi1 )
if ( i < list.size () - 1 ) ...

在这样的示例中,您很容易错过变量是自动递增/递减的,甚至删除了第一条语句。换句话说,仅在非常短的块中使用变量,或者仅在几个close语句中变量出现在块中的地方使用它。

2)如果有多个++和-关于同一条语句中的同一变量。很难记住在这种情况下会发生什么:

result = ( ++x - --x ) * x++;

考试和专业测试询问上述示例,的确,我在寻找有关其中一个示例的文档时偶然发现了这个问题,但在现实生活中,不应强迫人们对一行代码考虑太多。


1

Fortran是类似于C的语言吗?它既没有++也没有-。这是您编写循环的方式

     integer i, n, sum

      sum = 0
      do 10 i = 1, n
         sum = sum + i
         write(*,*) 'i =', i
         write(*,*) 'sum =', sum
  10  continue

每次通过循环,索引元素i都会由语言规则递增。例如,如果要增加1以外的值,请向后计数2,则语法为...

      integer i

      do 20 i = 10, 1, -2
         write(*,*) 'i =', i
  20  continue

是Python C一样吗?它使用范围列表理解以及其他语法来绕开增加索引的需要:

print range(10,1,-2) # prints [10,8.6.4.2]
[x*x for x in range(1,10)] # returns [1,4,9,16 ... ]

因此,基于对两种替代方案的初步探索,语言设计人员可以通过预期用例并提供替代语法来避免++和-。

与具有++和-的过程语言相比,Fortran和Python是否明显不吸引人?我没有证据。

我声称Fortran和Python就像C一样,因为我从未遇到过精通C的人,而他不能以90%的准确度正确猜测未混淆的Fortran或Python的意图。


1
是的,IFortran是1950年代的,而C是1970年代的,所以对于Fortran而言,可能与C类似。Python缺少诸如plusplus运算符之类的示例很有趣。在Python中更容易处理数据结构的迭代,Python是“不同的”面向对象的JavaScript。也许Crockford的建议是关于使用更多类似于OO的语法进行迭代。
artlung
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.