Первый вариант:
var a = 0, b = 0; имеет несколько явных недостатков:
1. При наличии системы контроля версий, добавление новой переменной будет неинформативно. Будет изменена вся строка, что незначительно усложнит ревью кода.
2. Субъективно подобная запись мешает восприятию кода. В ней плохо различимы переменные без присвоенного значения. Т.е. var a = 0, b = 0, c, d = 0;

Второй вариант:

var a = 0;
var b = 0;

Является наиболее расширяемым в плане версионирования (не имеет проблемы с выставлением запятой, как в приведенном ниже третьем варианте), но перегружен служебными словами.
Лично я предпочитаю пользоваться этим синтаксисом в nodejs модулях для подгрузки библиотек в верхней части скрипта:

var fs = require('fs');
var path = require('path');

Третий вариант:

var a = 0,
    b = 0;

Несколько проигрывает второму в плане удобства версионирования (при добавлении переменной С будет изменено две строчки, а не одна), но наиболее распространен в js best practices. Одинаково применим как с выравниванием по 4 пробелам для выстраивания переменных в столбик, так и без надуманного выравнивания.
Из минусов этого варианта, можно отметить забытую запятую после a = 0. В таком случае переменная b будет объявлена глобально, если не используется "use strict"

Нет, серьезно, вы не пробовали почитать учебные материалы по языку программирования, который используете?

Простите, вы собираетесь поэтапно решать свои задачи с помощью Тостера?
Судя по списку предыдущих ваших вопросов, именно так дела и обстоят.

Может стоит взять в руки учебник, ну или хотя бы javascript.ru проштудировать?

По поводу рабочего окружения:
Я бы порекомендовал уйти от Win XP хотя бы на Win 7. Из личного опыта - если вдруг у вас возникнет проблема с установкой модуля на Win XP никто даже не почешется помочь вам с отладкой.
Так же я порекомендовал бы Visual Studio 2010 или 2013. Здесь в большинстве случаев разницы не будет. После выбора используемой версии советую прописать npm config set msvs_version 2013 (или 2010 соответственно)
Стоит ознакомиться с рекомендациями приведенными в инструкции по работе с node-gyp

Установка нативых модулей в iojs это отдельная песня. Шанс что они скомпилируются как подмодули какого-то проекта нулевой, поскольку node-gyp не умеет компилировать под iojs, потому что не знает откуда качать его исходники. Поэтому Вам скорее всего придется устанавливать эти модули отдельно, компилировать их, а потом кидать в папку проекта.
Для компиляции используйте npm install -g pan-gyp. Это форк node-gyp созданный специально для компиляции под iojs. Собственно для компиляции модуля:
1. берем его с гитхаба
2. в package.json в секцию scripts прописываем preinstall: pan-gyp rebuild. (В случае модуля с которым вы мучаетесь, перезаписываем сразу install script)
3. Из директории модуля запускаем npm install .

У некоторых нативных модулей действительно есть скомпилированные бинарники, но это целиком ответственность разработчика модуля. И ответственность притом не малая. В случае вашего модуля, такие бинарники отсутствуют. Чаще всего при наличии бинарников у модуля в зависимостях будет висеть node-pre-gyp. (Примеры v8-profiler, v8-debug).
К слову для приведенных примеров вам совершенно необязательно что-либо перезаписывать.
Эти два модуля являются подмодулями node-inspector и в большинстве случаев устанавливаются без проблем.

В заключении:
Если не хотите вздрагивать при появлении в зависимостях проекта нативных модулей, то советую действительно использовать nodejs, так как компиляция под iojs еще очень не стабильна в плане инструментов.

Модуль, с которым вы мучаетесь, скорее всего вообще не тестировался на iojs.
Так же обратите внимание на package.json engine в этом пректе.