По большому счету есть кейсы когда можно, но нет кейсов — когда нужно )
В библиотеках часто используют "когда можно", чтобы код сократить (личное наблюдение).
Оох… этот контекст в highcharts! Библиотеки — это действительно отдельная тема )
Я разделяю недовольство по поводу нечистой стрелочной функции с this в примере, но готов иногда пойти на это ради читаемости.
Призыва переписывать все на классы не было. Но если бизнес-логика это позволяет, то пусть это будут классы… а не жгучая смесь подходов и танцы вокруг контекста.
Я бы не относил IIFE к явным возможностям ) но это повсеместная штука, ее трудно игнорировать. Мысль была хотя бы не спорить о синтаксисе.
Я пару раз видел изумление, когда показывал код тому же Java-разработчику. И да, считаю это хорошей практикой читать и понимать код не только JavaScript как для себя, так и для коллег. Мне эти операторы угодили, но в js они только называются «логическими» и часто понятны только js-разработчикам.
Ответ про разный результат был дан выше. Пример не об этом и мне стоило более четко выражать свою мысль и делать акцент. Постараюсь исправить ситуацию:
1. Верный вариант задать аргумент по умолчанию — это default parameters.
2. Если все таки нужно определить переменную по месту, то лучше не использовать «логический» оператор с проверкой наличия чего-либо.
3. Если в проверку еще добавляется валидация в несколько условий, то нормальный if statement еще более необходим. Хотелось бы верить, что это понятно (как было прокомментировано выше), но код с инициализацией переменной через кучу И и ИЛИ с проверками встречается.
А в чем вопрос? это не идентичные функции, просто примеры. Конечно надо дополнить нужной проверкой на число, на ноль если нужно. Поинт в том, что явная проверка аргумента понятнее себя ведет нежели специфичный «логический» оператор.
Мое скромное мнение в том, что не надо постоянно ссылаться на «легаси неочевидностей», показывая кому-то свой код ) Если вся команда — это JavaScript-мастера, то вопросов нет. Иначе стоит задуматься о возможностях языка быть понятнее, которыми он в конце концов располагает и не нуждается в deprecated (почти негде).
К сожалению линтером не обойтись… точки с запятой, скобки да strict equals. Многие вещи вполне допустимы для JavaScript-разработчика по самой природе языка, но со стороны очевидны не всем. И я специально не брал во внимание какое-то типизированное надмножество: у каждого свое ) но ведь можно в рамках приличия и без него.
Когда-то сам стал причиной повсеместного использования ~array.indexOf(x) во многих проектах компании. Но это такая себе практика, так как это не каждый js-разработчик то поймет на-лету, не то что проходящий мимо джавист или питонист. Сейчас убежден, что корпоративный код должен быть максимально понятен любому разработчику без разницы на каком языке. И если язык предоставляет готовый метод у массива/коллекции (Array.prototype.includes, не IE) или имеет широко-распространенную либу (lodash), то не надо использовать бинарные операции и прочие хаки не по назначению. Читаемость кода достигается не запоминанием каких-то специфичных конструкций, а декларативностью и явным поведением.
А в чем собственно разница? Мы все равно можем поменять значение f.count напрямую, а потом дергать func.getCount неправильно. Надумано? но если декорировать одну и ту же функцию дважды, то аукнется факт использования исходной функции в качестве хранилища счетчика: он обнулится. Модифицировать переданную функцию считаю не лучшей практикой:
const sum = (x, y) => x + y;
let f1 = func(sum);
f1(1, 2); // 3
f1.getCount(); // 1
let f2 = func(sum);
f1.getCount(); // 0 ?
Для обеспечения приватности нам необходимо использовать для замыкания локальную переменную в теле декорирующей функции.
Довольно старая статья об этом: When is it OK to use == in JavaScript?.
По большому счету есть кейсы когда можно, но нет кейсов — когда нужно )
В библиотеках часто используют "когда можно", чтобы код сократить (личное наблюдение).
Оох… этот контекст в highcharts! Библиотеки — это действительно отдельная тема )
Я разделяю недовольство по поводу нечистой стрелочной функции с this в примере, но готов иногда пойти на это ради читаемости.
Призыва переписывать все на классы не было. Но если бизнес-логика это позволяет, то пусть это будут классы… а не жгучая смесь подходов и танцы вокруг контекста.
Я бы не относил IIFE к явным возможностям ) но это повсеместная штука, ее трудно игнорировать. Мысль была хотя бы не спорить о синтаксисе.
Здесь будет строковое преобразование, так как один из операндов — явно строка. Но замечание очень дельное! с этим надо быть осторожным )
1. Верный вариант задать аргумент по умолчанию — это default parameters.
2. Если все таки нужно определить переменную по месту, то лучше не использовать «логический» оператор с проверкой наличия чего-либо.
3. Если в проверку еще добавляется валидация в несколько условий, то нормальный if statement еще более необходим. Хотелось бы верить, что это понятно (как было прокомментировано выше), но код с инициализацией переменной через кучу И и ИЛИ с проверками встречается.
www.youtube.com/watch?v=eGArABpLy0k&t=1m10s
А в чем собственно разница? Мы все равно можем поменять значение f.count напрямую, а потом дергать func.getCount неправильно. Надумано? но если декорировать одну и ту же функцию дважды, то аукнется факт использования исходной функции в качестве хранилища счетчика: он обнулится. Модифицировать переданную функцию считаю не лучшей практикой:
Для обеспечения приватности нам необходимо использовать для замыкания локальную переменную в теле декорирующей функции.