Fabric function of the others quadratic functions.

GetQuadraticFunction.js

function GetQuadraticFunction (a, b, c, d) {
	return (function (a, b, c, d) {

		function init (value, defaultValue) {
			value = parseFloat(value);
			
			if (Number.isNaN(value) || !Number.isFinite(value)) {
				value = defaultValue;
			}
			
			return value;
		}

		a = init(a, 1); b = init(b, 0); c = init(c, 0); d = init(d, 0);

		return function (x) {
			return a * Math.pow(x - d, 2) + b * (x - d) + c;
		}
	})(a, b, c, d);
}

1. Строки 2 и 15 не нужны.
2. Читалось бы намного удобнее, если бы были "говорящие" имена. q - занимается парсингом значений? Так и назови ее parse. v - это переданное значение, а w - значение по умолчанию? Так и назови их value и defaultValue.
3. Насчет парсинга и проверки значений. Есть два основных похода: первый, когда проверяют в функции входящие значения, пытаются их привести в нужный тип, при неудаче кидают ошибку или используют значение по умолчанию. И второй - когда вообще ничего делают. Предполагается, что тот кто вызывает код знает что он делает и пусть он сам отвечает за входящие данные. ИМХО, в данном случае вполне можно было-бы выбрать второй вариант. Задания буду читаться намного проще.

1. Не считаю строки 2 и 15 не нужными. Явное замыкание в функциях-фабриках - хорошая практика.
2. Да, с этим согласен. Имена можно дать и более подходящие.
3. Не уловил, что не так?

1. Замыкание и так есть, зачем еще одно?
2. Смущает что кода парсинга больше чем кода решающего задачу. Как вариант за пределы функции можно вынести. Тогда останется функция:

function GetQuadraticFunction (a, b, c, d) {
  a = init(a, 1); b = init(b, 0); c = init(c, 0); d = init(d, 0);

  return function (x) {
    return a * Math.pow(x - d, 2) + b * (x - d) + c;
  }
}

Совсем немного.

1. Я считаю формацию явного замыкания полезной. Может быть с точки зрения способностей языка это лишнее действие, но зато когда такое вижу однозначно знаю, что это фабрика. Знаю, что фабрика без использования переменных среды и привязки к внешнему контексту.
2. С таким же успехом можно вынести инициализацию аргументов в функцию обертку ))). А вообще вынести init за пределы хорошая решение, но это гист одной функции. В какой-нибудь библиотеке, где используется init неоднократно, решение даже не обсуждалось бы.

1. Т.е кроме "мне так удобно" никакого объяснения лишнему коду и потери производительности нет? ;) Кстати, что еще за "явное" замыкание? Есть "неявное"?
   Да и вообще, строки 2,15 не создают никакого замыкания. Если бы у тебя между строками 1 и 2 было объявление каких-нибудь переменных/функций, тогда бы да. А так просто немедленно вызываемая функция, используемая для создания локальной области видимости. Очевидно, что кроме как "для красоты" она тут ни для чего не нужна, она итак внутри функции.
2. Как хочешь, просто,кажется, лучше читалось бы.
3. В 7 строке у тебя что-то странное произошло, одно значение сравниваешь с булевским значением, другое нет:

if (Number.isNaN(value) || Number.isFinite(value) === false) {

По идее, как-то однородно должно быть:

if (Number.isNaN(value) || !Number.isFinite(value)) {

default кстати зарезервированное слово, должно ошибку кидать

1. Это просто квинтэссенция опыта. На дополнительном одноразовом вызове функции не создается потери производительности. Потерю создают циклы и утечка (ну и иррациональные алгоритмы). И закончим холивар, ото уже почти оскорбительно говорить об одном и том и объяснять одно и тоже.
2. Мы будем обсуждать как проверять значение на false? Серьезно? (Про default ты прав, поменял. Спасибо.)

Для чего же сделаны тут коментарии, как не для спора, в котором рождается мигрень)