是一个很好的特性。没有理由逃避。随着技术的发展，我们也必须自我进化。这个特性在Perl等一些语言中已经存在很长时间了。例如构建WebGL网格，新的javascript样式

   //initialize vertices with some calculated points
   [verts[ix],     verts[iy],     verts[iz]]     = ps[0];
   [verts[ix + 3], verts[iy + 3], verts[iz + 3]] = ps[1];
   [verts[ix + 6], verts[iy + 6], verts[iz + 6]] = ps[2];
   //initializing normals with cross products
   [norms[ix],     norms[iy],     norms[iz]]     = cr;
   [norms[ix + 3], norms[iy + 3], norms[iz + 3]] = cr;
   [norms[ix + 6], norms[iy + 6], norms[iz + 6]] = cr;

事实上，老式的代码更难调试，到目前为止也更难理解和发现任何bug。这个样本过于简化了。大量重复的例程阻碍了真正的逻辑，使代码看起来像某种魔法。和上面一样，不过是古风:

      //initialize vertices with some calculated points
      verts[ix]     =  ps[0][0];
      verts[iy]     =  ps[0][1];
      verts[iz]     =  ps[0][2];
      verts[ix + 3] =  ps[1][0];
      verts[iy + 3] =  ps[1][1];
      verts[iz + 3] =  ps[1][2];
      verts[ix + 6] =  ps[2][0];
      verts[iy + 6] =  ps[2][1];
      verts[iz + 6] =  ps[2][2];
      //initializing normals with cross products
      norms[ix]     =  cr[0];
      norms[iy]     =  cr[1];
      norms[iz]     =  cr[2];
      norms[ix + 3] =  cr[0];
      norms[iy + 3] =  cr[1];
      norms[iz + 3] =  cr[2];
      norms[ix + 6] =  cr[0];
      norms[iy + 6] =  cr[1];
      norms[iz + 6] =  cr[2];

注意，在迁移新样式的代码时，我不仅大量删除了大块的例程代码。我很容易就发现了那些逃避了大量代码审查的不一致之处，这只是因为我让代码更容易可视化，更简洁，更面向逻辑，更不面向例程。

也许像这样

var variable1 = "Hello, World!"
, variable2 = 2
, variable3 = "How are you doing?"
, variable4 = 42;

除了更改第一个或最后一个变量外，它易于维护和读取。

这样做的时候可读性更强:

var hey = 23;
var hi = 3;
var howdy 4;

但是这种方法占用的空间和代码行数更少:

var hey=23,hi=3,howdy=4;

它是节省空间的理想选择，但是让JavaScript压缩器为您处理它。

除了可维护性，第一种方法消除了意外创建全局变量的可能性:

(function () {
var variable1 = "Hello, World!" // Semicolon is missed out accidentally
var variable2 = "Testing..."; // Still a local variable
var variable3 = 42;
}());

而第二种方式就不那么宽容了:

(function () {
var variable1 = "Hello, World!" // Comma is missed out accidentally
    variable2 = "Testing...", // Becomes a global variable
    variable3 = 42; // A global variable as well
}());

使用ES6解构赋值:它会将数组中的值或对象中的属性解压缩到不同的变量中。

Let [variable1, variable2, variable3] = ["Hello, World!"， "Testing…"，42]; console.log (variable1);//你好，世界! 如上所述console.log(的操作);/ /测试…… console.log (variable3);/ / 42

正如每个人都说的，这主要是偏好和可读性，但我将在这个帖子上发表评论，因为我没有看到其他人分享这样的想法

我认为这个问题的答案很大程度上取决于你所设置的变量以及它们之间的关系。我尝试着基于我所创造的变量是否相关而保持一致;我的偏好大致是这样的:

对于不相关的变量

我把它们排成一行，这样以后可以很容易地移动它们;我个人从来不会以其他方式声明不相关的项目:

const unrelatedVar1 = 1;
const unrelatedVar2 = 2;
const unrelatedVar3 = 3;

对于相关的东西(实用程序)

如果我要创建一个新变量，我将其声明为一个块——这提示属性属于一起

const
  x = 1,
  y = 2,
  z = 3
;

// or
const x=1, y=2, z=3;

// or if I'm going to pass these params to other functions/methods
const someCoordinate = {
  x = 1,
  y = 2,
  z = 3
};

对我来说，这更符合解构:

const {x,y,z} = someCoordinate;

这样做会让人觉得很笨拙(我不会这么做)

const x = someCoordiante.x;
const y = someCoordiante.y;
const z = someCoordiante.z;

相关事宜(建筑)

如果用同一个构造函数创建了多个变量，我通常也会将它们分组在一起;我个人觉得这样更有可读性

而不是(我通常不这么做)

const stooge1 = Person("moe");
const stooge2 = Person("curly");
const stooge3 = Person("larry");

我通常会这样做:

const [stooge1, stooge2, stooge3] = ["moe", "curly", "larry"].map(Person);

我说通常是因为如果输入参数足够长，这会变得不可读，我会把它们分开。

我同意其他人关于严格使用的评论