在JavaScript中:

var something = 12;

function nicelyCraftedFunction()
{
  something = 13;
  // ... some other code
  // ... and in Galaxy far, far away this:
  if( false ) // so the block never executes:
  { 
    var something; 
  }
}
nicelyCraftedFunction(); // call of the function

通常你会期望某个变量的值是13。 但在JavaScript中不是这样——变量有函数作用域，所以后面的声明会影响上游的一切。

在使用C/ c++ /Java表示法的语言(如JS)中，你会期望变量具有块范围，而不是像这样…

因此，编译器甚至可以从最终生成的字节码中删除的死代码块仍然会对正常执行的其余代码产生副作用。

因此，在调用函数之后，某些东西仍然是12 -不变的。

在FoxPro中，如果我没记错的话，每个命令都可以缩写为4个字符，其他的都被忽略，所以READ, READY, READINESS都是一样的——前4个字符之后的都被忽略。向我解释的人喜欢这个功能，但我觉得它很恐怖。

在javaScript中，NaN是一个全局变量。

Perl的$[(已弃用)，这在之前关于通用Perl变量的另一篇文章中提到过，但它值得特别提到，并有更好的解释。对$[的更改仅限于当前范围。更多的信息以及如何使用它的含义;)可以在$[中找到，请访问http://www.perlmonks.org/index.pl/?node_id=480333

在JavaScript中，下面的构造

return
{
    id : 1234,
    title : 'Tony the Pony'
};

返回undefined是一个语法错误，因为在返回后的换行上偷偷地插入了分号。以下工作正如你所期望的那样:

return {
    id : 1234,
    title : 'Tony the Pony'
};

更糟糕的是，这个也可以(至少在Chrome中):

return /*
*/{
    id : 1234,
    title : 'Tony the Pony'
};

下面是同一个问题的一个变种，它不会产生语法错误，只是无声地失败了:

return
    2 + 2;

在fortran中(当然是77，可能在95中也是如此)，未声明的变量和以I到N开头的参数(“In”组)将是INTEGER，所有其他未声明的变量和参数将是REAL(源)。这与“在某些情况下可选的空白”相结合，导致了最著名的错误之一。

正如弗雷德·韦伯在1990年的《另类民间传说:计算机》一书中所说:

I worked at Nasa during the summer of 1963. The group I was working in was doing preliminary work on the Mission Control Center computer systems and programs. My office mate had the job of testing out an orbit computation program which had been used during the Mercury flights. Running some test data with known answers through it, he was getting answers that were close, but not accurate enough. So, he started looking for numerical problems in the algorithm, checking to make sure his tests data was really correct, etc. After a couple of weeks with no results, he came across a DO statement, in the form: DO 10 I=1.10 This statement was interpreted by the compiler (correctly) as: DO10I = 1.10 The programmer had clearly intended: DO 10 I = 1, 10 After changing the . to a , the program results were correct to the desired accuracy. Apparently, the program's answers had been "good enough" for the sub-orbital Mercury flights, so no one suspected a bug until they tried to get greater accuracy, in anticipation of later orbital and moon flights. As far as I know, this particular bug was never blamed for any actual failure of a space flight, but the other details here seem close enough that I'm sure this incident is the source of the DO story.

我认为这是一个很大的WTF，如果DO10I被作为DO10I，并且反过来，因为隐式声明被认为是类型REAL。这是个很棒的故事。