Наконец то нормальные хинты, а не просто перечисление функций консоли. От себя добавлю что код можно редактировать прямо в дебаггере, сохранять по Ctrl+S и исполняться будет уже измененный код. Но работает это только с отключенным sourceMap.
Мне не кажется что этот комментарий тянет на отличный. Из кода и так понятно что он делает. А решать архитектурные проблемы комментариями вообще плохая идея. Лучше продумать обязательность/необязательность key.
Разрешите пример хорошего комментария, на мой взгляд:
// not using Number.isFinite here because it must work in IE11 without polifill
if(!isFinite(arg)) return;
...
Тут четко понятно почему сделано так а не иначе, как раз в духе «не что, а зачем»
Позволю себе совет. Перепишите на typescript. Ну и еще один, попросите опытных товарищей сделать codereview вашему коду. Я пробежался по диагонали, есть явные места где стоит чуть переделать, например
//....
return nstd.Structure.sort((a, b) => {
if (a.lkey > b.lkey) return 1
if (a.lkey < b.lkey) return -1
return 0
})
// better replace with
return nstd.Structure.sort((a, b) => a.lkey - b.lkey )
Чего это вы так взбеленились? Это ваши модули? С чего вы взяли что я не создаю issue? Я на такое ругался еще со времен jquery плагинов и browserify, который этим то же страдал даже в большей степени.
К тому же, обычно лишние файлы не видно, нужно специально лезть в модули, что делается крайне редко. Замечать это начинаешь когда inodes заканчиваются и тормозит IDE. Вот тогда и подбешивает, смотришь на размеры папок и сносишь модули в старых проектах.
Почему JavaScript-программисты испытывают проблемы при использовании ключевого слова this?
Программисты не испытывают проблем при использовании слова this. Проблемы испытывают недопрограммисты. А вообще, я бы на собесах просил написать три функции для числа фибоначчи: рекурсивно, динамическим программированием и с помощью генераторов. Если человек это все знает и умеет, с высокой вероятностью он программист. Недостаток знаний по либам и тулзам не важен. Решать гуано-кодище в уме, что выведет фигня за которую в реальности нужно рубить пальцы… Зачем такие вопросы, мне не понятно.
Я ничего в примере выше не округлял, это за меня арифметика с плавающей запятой справилась. float нельзя вообще использовать ни для чего, что дожно сохранять точность, это аксиома.
Абсолютно согласен.
И про деньги согласен. Но это нужно обговаривать. И на входе не строки, а числа.
Ну вы прочитайте выше то, елки палки! Да я именно об этом и говорю! Нельзя так с рациональными числами — считать, округлять, опять считать и ожидать что все сойдется. И именно по этому я критикую этот подход так яростно.
Еще хуже вариант. Я б такому калькулятору точно не доверял.
Давайте сразу уточним, речь идет о float, не об int. Смотрите, я делю 100 на 3. Получаю 33 и 3 в периоде. А вижу
["33.333", "33.333", "33.334" ]
Как вы мне объясните что у меня одно(последнее) число больше чем первые два? Это точно подтасовка.
С другой стороны, умножая 33.333 * 3 я получу «100.00» или «99.999».
Это, опять же, совершенно другая задача.
Разбить целое на целые доли ну вот нифига не тоже самое что вывести массив процентов в строках с округлением до 3 знаков. Я даже рад что не прошел то интервью. Если просят ставят одну задачу, а решение ожидают от другой, то я наверное никогда так не смогу.
Ну очевидно, первое что приходит — не применять округление для промежуточных результатов. Округление — последняя операция. И с каких это пор подгонка результата вычислений под желаемое — нормальная операция?
Не переворачивайте исходные условия, пожалуйста. Задача звучала не так. То что вы просите — другая задача. Задача была вернуть массив округленных строк.
ЗЫ А вот почему потом вдруг эти строки начинают участвовать в математике, для меня тоже вопрос.
Инженерно? Хм… Про погрешности я не буду тут рассказывать, но это не инженерно, поверьте.
Во первых, правильно будет форматировать результат, а не округлять в промежуточных вычислениях.
Во вторых. результат, как я уже упомянул — строки. Нахрена вам строки складывать? Если вы знаете что потом с результатом будут дальше проводиться вычисления, зачем округлять?
В третьих, даже если так поступать, почему погрешность прибавлять к последнему? Чем последний элемент лучше чем первый, или второй, или рандомный?
Это не математика, это фальсификация. Такими математиками только печь топить.
Что такое ButterflyNet? В статье ни ссылок ни информации. Это ваш проект? С открытым кодом?
JSX был важнейшим нововведением. (я щщетаю). Все остальное холивар. Но да, теперь мы поуши в этом реакте.
ВоскреснЕте.
Наконец то нормальные хинты, а не просто перечисление функций консоли. От себя добавлю что код можно редактировать прямо в дебаггере, сохранять по Ctrl+S и исполняться будет уже измененный код. Но работает это только с отключенным sourceMap.
Разрешите пример хорошего комментария, на мой взгляд:
Тут четко понятно почему сделано так а не иначе, как раз в духе «не что, а зачем»
уверен что будут и более веские замечания.
К тому же, обычно лишние файлы не видно, нужно специально лезть в модули, что делается крайне редко. Замечать это начинаешь когда inodes заканчиваются и тормозит IDE. Вот тогда и подбешивает, смотришь на размеры папок и сносишь модули в старых проектах.
И про деньги согласен. Но это нужно обговаривать. И на входе не строки, а числа.
Давайте сразу уточним, речь идет о float, не об int. Смотрите, я делю 100 на 3. Получаю 33 и 3 в периоде. А вижу Как вы мне объясните что у меня одно(последнее) число больше чем первые два? Это точно подтасовка.
С другой стороны, умножая 33.333 * 3 я получу «100.00» или «99.999».
Видно что происходит? Потеря точности неизбежна. И вот этот аргумент, что пользователь и программе не доверяет, и сам считать не умеет, ну извинити…
Разбить целое на целые доли ну вот нифига не тоже самое что вывести массив процентов в строках с округлением до 3 знаков. Я даже рад что не прошел то интервью. Если просят ставят одну задачу, а решение ожидают от другой, то я наверное никогда так не смогу.
ЗЫ А вот почему потом вдруг эти строки начинают участвовать в математике, для меня тоже вопрос.
Во первых, правильно будет форматировать результат, а не округлять в промежуточных вычислениях.
Во вторых. результат, как я уже упомянул — строки. Нахрена вам строки складывать? Если вы знаете что потом с результатом будут дальше проводиться вычисления, зачем округлять?
В третьих, даже если так поступать, почему погрешность прибавлять к последнему? Чем последний элемент лучше чем первый, или второй, или рандомный?
Это не математика, это фальсификация. Такими математиками только печь топить.