这只是个人喜好的问题。这两种方式之间没有区别，只是如果去掉空白，第二种形式节省了一些字节。

var variable1 = "Hello, World!";
var variable2 = "Testing...";
var variable3 = 42;

比:

var variable1 = "Hello, World!",
    variable2 = "Testing...",
    variable3 = 42;

但它们做的事情是一样的。

第一种方法更容易维护。每个声明都是单行上的单个语句，因此可以轻松地添加、删除和重新排序声明。

对于第二种方法，删除第一个或最后一个声明是很烦人的，因为它们分别从var关键字开始并以分号结束。每次添加新声明时，必须将最后一行中的分号替换为逗号。

对于组织来说，每个作用域使用一个var语句是很常见的。所有“作用域”都遵循类似的模式，使代码更具可读性。此外，引擎会把它们都“吊”到顶部。因此，将声明放在一起可以更紧密地模拟实际发生的情况。

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

(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
}());

也许像这样

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压缩器为您处理它。

我唯一的，也是最重要的，逗号的用法是在for循环中:

for (var i = 0, n = a.length; i < n; i++) {
  var e = a[i];
  console.log(e);
}

我在JavaScript中查看了一下这个是否可以。

即使它是可行的，一个问题仍然是n是否对函数是局部的。

这验证了n是本地的:

a = [3, 5, 7, 11];
(function l () { for (var i = 0, n = a.length; i < n; i++) {
  var e = a[i];
  console.log(e);
}}) ();
console.log(typeof n == "undefined" ?
  "as expected, n was local" : "oops, n was global");

在语言之间切换，我一时拿不准。

我认为第一种方法(多个变量)是最好的，否则你就会得到这样的结果(来自使用KnockoutJS的应用程序)，这在我看来很难理解:

    var categories = ko.observableArray(),
        keywordFilter = ko.observableArray(),
        omniFilter = ko.observable('').extend({ throttle: 300 }),
        filteredCategories = ko.computed(function () {
            var underlyingArray = categories();
            return ko.utils.arrayFilter(underlyingArray, function (n) {
                return n.FilteredSportCount() > 0;
            });
        }),
        favoriteSports = ko.computed(function () {
            var sports = ko.observableArray();
            ko.utils.arrayForEach(categories(), function (c) {
                ko.utils.arrayForEach(c.Sports(), function (a) {
                    if (a.IsFavorite()) {
                        sports.push(a);
                    }
                });
            });
            return sports;
        }),
        toggleFavorite = function (sport, userId) {
            var isFavorite = sport.IsFavorite();

            var url = setfavouritesurl;

            var data = {
                userId: userId,
                sportId: sport.Id(),
                isFavourite: !isFavorite
            };

            var callback = function () {
                sport.IsFavorite(!isFavorite);
            };

            jQuery.support.cors = true;
            jQuery.ajax({
                url: url,
                type: "GET",
                data: data,
                success: callback
            });
        },
        hasfavoriteSports = ko.computed(function () {
            var result = false;
            ko.utils.arrayForEach(categories(), function (c) {
                ko.utils.arrayForEach(c.Sports(), function (a) {
                    if (a.IsFavorite()) {
                        result = true;
                    }
                });
            });
            return result;
        });

“内聚优于耦合”的概念可以更广泛地应用，而不仅仅是对象/模块/函数。它还可以用于以下情况:

OP建议的第二个示例将所有变量耦合到同一个语句中，这使得不可能在不破坏东西的情况下将其中一行移动到其他地方(高耦合)。他给出的第一个例子使得变量分配彼此独立(低耦合)。

从耦合:

低耦合通常是结构良好的计算机系统和良好设计的标志，当与高内聚相结合时，可以支持高可读性和可维护性的总体目标。

所以选择第一个。

虽然两者都是有效的，但使用第二种方法会使缺乏经验的开发人员不愿意到处放置var语句，从而导致提升问题。如果每个函数只有一个var，在函数的顶部，那么从整体上调试代码会更容易。这可能意味着声明变量的行不像某些人希望的那样显式。

我觉得这种权衡是值得的，如果这意味着让开发者不再在任何他们喜欢的地方使用“var”。

人们可能会抱怨JSLint，我也一样，但是很多JSLint并不是为了修复语言的问题，而是为了纠正编码员的坏习惯，从而防止他们编写的代码出现问题。因此:

在具有块作用域的语言中，通常建议在第一次使用变量的位置声明变量。但是因为JavaScript没有块作用域，所以更明智的做法是在函数的顶部声明函数的所有变量。建议每个函数使用一个var语句。”——http://www.jslint.com/lint.html范围

我认为这是个人喜好的问题。我喜欢用下面的方法做这件事:

   var /* Variables */
            me = this, that = scope,
            temp, tempUri, tempUrl,
            videoId = getQueryString()["id"],
            host = location.protocol + '//' + location.host,
            baseUrl = "localhost",
            str = "Visit W3Schools",
            n = str.search(/w3schools/i),
            x = 5,
            y = 6,
            z = x + y
   /* End Variables */;

避免使用单语句版本(单var)的另一个原因是调试。如果在任何赋值行中抛出异常，堆栈跟踪只显示这一行。

如果使用逗号语法定义了10个变量，则无法直接知道哪个变量是罪魁祸首。

单个语句版本没有这种歧义。

ECMAScript 2015引入了解构赋值，效果非常好:

[a, b] = [1, 2]

A等于1 b等于2。

我相信在我们开始使用ES6之前，使用单一的var声明的方法既不好也不好(如果你有lints和'use strict'的话)。这真的是一种口味偏好。但现在我的情况变了。以下是我对多行声明的一些看法:

Now we have two new kinds of variables, and var became obsolete. It is good practice to use const everywhere until you really need let. So quite often your code will contain variable declarations with assignment in the middle of the code, and because of block scoping you quite often will move variables between blocks in case of small changes. I think that it is more convenient to do that with multiline declarations. ES6 syntax became more diverse, we got destructors, template strings, arrow functions and optional assignments. When you heavily use all those features with single variable declarations, it hurts readability.

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

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

可维护性问题可以很容易地通过一些格式化来解决，比如:

let
  my_var1 = 'foo',
  my_var2 = 'bar',
  my_var3 = 'baz'
;

我严格按照个人喜好使用这种格式。当然，对于单个声明，或者它只是把工作搞砸的情况，我跳过了这种格式。

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

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

对于不相关的变量

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

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);

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

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

有c背景的人肯定会使用第二种方法

var variable1 = "Hello, World!",
variable2 = "Testing...",
variable3 = 42;

上面的方法看起来更像c语言

第二种方法的主要问题是，到目前为止还没有IDE支持这种风格。 你不能折叠这些结构。

我们可以使用所有的方法，没有必要只选择其中一种。应用不同的方法可以使代码更易于阅读。

我将展示我Vue.js 3项目中的一个真实例子:

示例1

const [store, route] = [useStore(), useRoute()]
        
const    
   showAlert = computed(() => store.getters['utils/show']),
   userIsLogged = computed(() => store.getters['auth/userIsLogged']),
   albumTitle = computed(() => store.getters['albums/title']);

示例2

const    
   store = useStore(),
   username = ref(''),
   website = ref(''),
   about = ref('');

const 
   isAppFirstRender = computed(() => store.getters['utils/isAppFirstRender']),
   showToast = ref(false);

正如你在上面看到的，我们可以有一小块变量声明。没有必要声明大块。假设我有12个变量，我可以以一种有意义或看起来更容易阅读的方式将它们分组，而不需要冗长:

const
  numberOne = 5,
  numberTwo = 10,
  numberThree = 15;

const
  stringOne = 'asd',
  stringTwo = 'asd2',
  stringThree = 'asd3';

let [one, two, three] = [1,2,3]

当然，每个人都有自己的风格。这是我个人的偏好，混合使用所有方法。

我个人不喜欢冗长。我喜欢有它所需要的而不是更多的代码。

是一个很好的特性。没有理由逃避。随着技术的发展，我们也必须自我进化。这个特性在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];

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