Пасоны, как правильно парсить параметры?
 

Пасоны как правильно и общепринято парсить параметры и как для этого оформляется jsdoc?


у меня логика такая, параметры парсятся слева направо,
первая функция что попадет это геттер, вторая функция что попадет это сеттер, если попадет массив то это массив строк aliases.

При чем ни один параметр не обязателен. Как тут быть?

1) как правильно общепринято парсить параметры?
2) как для этого оформить jsdoc чтобы гугл не ругался

А зачем тебе парсить их? пишеш докогенератор? уже есть готовые, например jsdoc3.

Чтобы гугл не ругался, нужно использовать их синтаксис jsdoc, он прекрасно описан у них. В твоем примере синтаксис не валиден гугловскому.

ЗЫ: к шторму можно подключить Closure Linter для валидации jsdoc в гугловском стиле, может помогать.
ЗЫЗЫ: возможно я не понял твой вопрос :)

да нет О_О, наоборот О_О я охренел аж, круто, а можешь написать jsdoc для моего случая?

/**
 * TODO  сделать описание
 *
 * @param {Function|String[]} [getter]
 * @param {Function|String[]} [setter]
 * @param {Function|String[]} [aliases]
 *
 * @constructor
 */
function ProxyCap (getter, setter, aliases) {

	this.getter = null;
	this.setter = null;
	this.aliases = null;

	// парсим параметры
	for (var i = 0; i < arguments.length; i++) {
		var arg = arguments[i];

		if (arg instanceof Function) {
			this[this.getter ? 'setter' : 'getter'] = arg;
		} else if (arg instanceof Array) {
			this.aliases = arg;
		}
	}

}

нет, у меня конструктор который имеет динамический интерфейс..

new ProxyCap();
new ProxyCap(function getter(){}, ['aliases']);
new ProxyCap(['aliases'], function getter(){});
new ProxyCap(['aliases'], function getter(){}, function setter(){});
new ProxyCap(function getter(){}, ['aliases'], function setter(){});
new ProxyCap(function getter(){}, function setter(){}, ['aliases']);

все и работает, пнятна)?

это по аналогии с css свойствами где разное количество разных параметров

Т.к. JS не имеет нормальных перегрузок, то такие интерфейсы описываются довольно кривовато:

/**
 *
 * @param {...Function|Array.<string>} args - неведомая хрень, которая принимает не ограниченное количество опциональных параметров
 */
function ProxyCap (args) {

kobezzza,
и гугл это схавает?

Да, но маловероятно, что сможет провести дополнительный оптимизации или инлайнинг для такой функции.

да мне главное от варнингов избавится если честно. стоп, а если просто доку убрать О_О ну в смысле вторую звездочку вначале и оставить доку только для себя.

То варнингов не будет.

kobezzza,
а кстати ты юниттестируешь то что гуглом откомпилено? или если он предупреждений не выдает то и тестировать не надо? и как вообще можно протестировать такой код?

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

Для тестов я в основном юзаю qUnit.

кстати ты его юзаешь, он ругается на выравнивания разные, как это настраивать и вообще где у него доки? я не смог найти.

как покрыть откомпилированный код юниттестами? там же именя другие е мае) как МИНИМУМ

Не юзаю, тоже не до конца разобрался с настройками и забил. Настраивается с помощью конфиг файла. Для справки вызови --help в консольке.
А ваще у гугла много мутных велосипедов, и это один из них.

Ну всё конечно не покрыть, т.к. что-то инлайнится, что-то удаляется, но если я жму либу, то у мя есть "внешние ручки", которые не меняют названия.

Если проверяю проект, то использую приёмочные и интеграционные тесты.

как ты понял я это уже сделал и получил "ко ко ко")

ну я думал что суть юнит тестов в том чтобы тестировать каждый класс и каждый метод независимо, ну да ладно.

штоэта О_О?

Ну остальное тестится в несжатом виде, тут уже ничего не поделаешь.

Мир гораздо разнообразнее и существует over9000 различных видов тестов и отдельные профессии "тестировщик {подставить нужное}".

Интеграционные тесты - это тесты взаимодействия модулей.
Приёмочные тесты - это самые абстрактные тесты, которые проверяют работу проекта в целом: например можно написать тест на Selenium IDE который будет из браузера ходить по сайтеку, что-то делать и т.д. а результат сравниваться вручную или опять таки программно. Тестирование сервиса "вручную" тоже считается приёмочным тестированием.

kobezzza, я чо то похожее видал у вижуал студии. Там типа тонны разных тулсов для такого, не?

Не могу знать, я студию так глубоко никада не юзал:)