хорошее видео, но в начале было сказано про оптимизации а на деле оказалось просто сокращением кода P.S.: в 4-м примере исходный и итоговый варианты не эквивалентны
Попробую дополнить некоторые примеры. #2 Можно решить так: v = d != null && d !== '' && d; ...или даже так: v = d !== '' && d ?? false; #4 Для функции-предиката корректнее будет возвращать результат требуемой проверки, а не значение свойства объекта, потому что оно ведь может быть и ложноподобным (falsy). const checkProp = (obj, key) => obj[key] != null; Хотя вместо этой функции, наверное, лучше просто использовать оператор in или метод hasOwnProperty (без свойств прототипов). Например, 2 in nobj или nobj.hasOwnProperty(2) #5 Предложенный вариант довольно интересен, вызов функции действительно можно выносить за скобки. Но если функции не переиспользуются, то их всё же проще заинлайнить. res5 = ( typeof t5 === 'string' ? t5.length > 8 : t5 > 100 ); #6 Если ноль не причислять (как сделано в видео) к негативным значением, то можно решить ещё и так: value = ['negative', 'zero', 'positive'][Math.sign(num) + 1]; #9 Деструктурирующее присваивание будет конечно же лучшим решением, но для числовых значений вполне возможно и такое: w1 = w2 - (w2 = w1, 0);
насчет оператора нулевого слияния: это новый оператор, без которого можно обойтись условием на condition != undefined. именно != т.к. нестрогое сравнение на undefined также приводит и к null, т.к. nul == undefined вернет true, но null === undefined вернет false
@@olegkravchenko9655 да, но лучше undefined: null мы проставляем сами, а undefined показывает, что такого нет вообще, а не то что мы проставили значение на null
Гребаные оптимизаторы. Переменные называй однобуквенно ещё для экономии. Вы для какого процессора программируете? Z80 на машкоде? Циклы узкое место для любого процессора, там стоит упирать на оптимизацию, во всех остальных случаях читаемость предпочтительнее.
Тернарный оператор начал применять после Ваших видео)) попробую что-нибудь оптимизировать в последнем проекте) На счет примера #7, в проекте использую EJS и объекты с инфойдля карточек товара/слайдеров/новостей или еще чего-нибудь, что можно вывести в цикле и как раз через forEach прогоняю всегда и вопрос, как называется последний метод?)
Про системы счисления - вот это и плохо в javascript, что язык пытается предполагать за тебя. Тип аргумента не подходит в операции, язык не глядя приведет к строке. Или к числу, как захочет. parseInt - сам как хочет подставляет систему счисления. Полный бардак в языке.
1 пример гораздо лучше, ИМХО, решить через switch: switch(roleName) { case 'role1' : case 'role2' : case 'role3' : Код... Почему лучше, чем поиск в массиве? Это наглядней, и гораздо быстрее рефакторить. Если завтра для role2 надо поменять код на совершенно другой - сразу ясно что и где править и даже условие для выборки роли практически готово - не надо писать ещё один массив и ещё один блок if. Ну и switch обрабатывается быстрее чем if и поиск в массиве
В вашем примере стрелочная функция checkProp не является полным аналогом обычной функции, так как возвращает либо строку либо false. Обычная же возвращала true or false.
Как я понимаю (не претендую на истинность, чисто обывательское мнение), оптимизация - уменьшение потребления кода. Чаще всего когда говорят об оптимизации программы, говорят о сокращении использования памяти, либо об ускорении выполнения. Рефакторинг же - упрощение кода в угоду его читаемости. Считать ли сокращение времени на восприятие кода (т.е. затрату человеко-часов) оптимизацией - вопрос открытый к обсуждению. Рефакторинг может приводить к оптимизации потребления, но это не его самоцель, скорее просто сайд-эффект. С этой стороны скорее "реинжиниринг" будет больше походить на оптимизацию, хотя опять же, это не одно и то же. Повторюсь, чисто обывательское мнение.
Оптимизация = правильное применение алгоритмов = ускорение кода; Рефакторинг = читабельность = ускорение разработки и расширяемость. У меня так, пока что, в голове.
В 6ом примере я бы использовал Number() с регулярным выражением, тогда будет не важно, целые числа, есть ли в них буквы или нет, причем когда parseInt/Float уже не справляются: let regx = /[a-z]/g; let str = '2.4f'; console.log(Number(str.replaceAll(regx, ""))) //2.4 console.log(parseInt(str)) // NaN
@@TheKorolariya Так это же число, зачем его через регулярно прогонять. Зависит же от ситуации) Тот мой код это не панацея, чисто чтобы быстро избавиться от грязных чисел, не более)
Здравствуйте! 1 пример: const userRole = `guest`; switch (userRole){ case `guest`: case `manager`: case `affiliate`: console.log(`Можно`); break; } Как вам это? плохо или хорошо? или лучше switch использовать только тогда когда у нас есть несколько if? Заранее спасибо за ответы и советы!
Ну по поводу стрелочных функций то вся их прелесть не в сокращении написания кола, а в привязке к контексту :) а писать коротко в одну строку функции часто бывает на много менее читабельно и сложнее для понимания, особенно когда на проекте работает несколько человек.
хорошее видео, но в начале было сказано про оптимизации
а на деле оказалось просто сокращением кода
P.S.: в 4-м примере исходный и итоговый варианты не эквивалентны
Попробую дополнить некоторые примеры.
#2 Можно решить так:
v = d != null && d !== '' && d;
...или даже так:
v = d !== '' && d ?? false;
#4 Для функции-предиката корректнее будет возвращать результат требуемой проверки, а не значение свойства объекта, потому что оно ведь может быть и ложноподобным (falsy).
const checkProp = (obj, key) => obj[key] != null;
Хотя вместо этой функции, наверное, лучше просто использовать оператор in или метод hasOwnProperty (без свойств прототипов). Например, 2 in nobj или nobj.hasOwnProperty(2)
#5 Предложенный вариант довольно интересен, вызов функции действительно можно выносить за скобки. Но если функции не переиспользуются, то их всё же проще заинлайнить.
res5 = (
typeof t5 === 'string'
? t5.length > 8
: t5 > 100
);
#6 Если ноль не причислять (как сделано в видео) к негативным значением, то можно решить ещё и так:
value = ['negative', 'zero', 'positive'][Math.sign(num) + 1];
#9 Деструктурирующее присваивание будет конечно же лучшим решением, но для числовых значений вполне возможно и такое:
w1 = w2 - (w2 = w1, 0);
Глядя на статус-бар в Visual code, можно подумать, что автор сидит под windows XP. У меня реально были такие мысли, когда я превьюху увидел.
Однозначно лайк, очень полезные видео делаешь отец!
В 8ом совете приведение к числе через Number - гораздо читабельнее будет всех остальных трикшотов!
+ не поможет, при : «100%» или «100px» только parseInt поможет. Спасибо за урок! Здоровья Вам!
насчет оператора нулевого слияния: это новый оператор, без которого можно обойтись условием на condition != undefined. именно != т.к. нестрогое сравнение на undefined также приводит и к null, т.к. nul == undefined вернет true, но null === undefined вернет false
condition != null
Тоже самое, но чуть короче :)
@@olegkravchenko9655 да, но лучше undefined: null мы проставляем сами, а undefined показывает, что такого нет вообще, а не то что мы проставили значение на null
Гребаные оптимизаторы. Переменные называй однобуквенно ещё для экономии. Вы для какого процессора программируете? Z80 на машкоде? Циклы узкое место для любого процессора, там стоит упирать на оптимизацию, во всех остальных случаях читаемость предпочтительнее.
Поддерживаю
Меня поражает работоспособность Александра, как, где найти столько сил?
это прям золото видос, побольше таких)
Люблю этот канал!
4:40
if (!d) {
// сделай что то
}
магияяя....
По факту
Все доходчиво разжевано. Спасибо.
Тернарный оператор начал применять после Ваших видео)) попробую что-нибудь оптимизировать в последнем проекте)
На счет примера #7, в проекте использую EJS и объекты с инфойдля карточек товара/слайдеров/новостей или еще чего-нибудь, что можно вывести в цикле и как раз через forEach прогоняю всегда
и вопрос, как называется последний метод?)
Деструктурирующее присваивание
Спасибо, надеюсь на продолжение
Про системы счисления - вот это и плохо в javascript, что язык пытается предполагать за тебя. Тип аргумента не подходит в операции, язык не глядя приведет к строке. Или к числу, как захочет. parseInt - сам как хочет подставляет систему счисления. Полный бардак в языке.
Большое спасибо за советы
Круто, спасибо.
Полезно. Благодарю.
1 пример гораздо лучше, ИМХО, решить через switch:
switch(roleName) {
case 'role1' :
case 'role2' :
case 'role3' :
Код...
Почему лучше, чем поиск в массиве? Это наглядней, и гораздо быстрее рефакторить. Если завтра для role2 надо поменять код на совершенно другой - сразу ясно что и где править и даже условие для выборки роли практически готово - не надо писать ещё один массив и ещё один блок if. Ну и switch обрабатывается быстрее чем if и поиск в массиве
В вашем примере стрелочная функция checkProp не является полным аналогом обычной функции, так как возвращает либо строку либо false. Обычная же возвращала true or false.
Было бы круто, если бы задачки были по этой теме!
Так забавно наблюдать как фронтендер изобретает хеш таблицу и Null Coalescing
Александр, а можете вот также объяснить на примерах в видео-формате в чём разница оптимизации и рефакторинга?
Как я понимаю (не претендую на истинность, чисто обывательское мнение), оптимизация - уменьшение потребления кода. Чаще всего когда говорят об оптимизации программы, говорят о сокращении использования памяти, либо об ускорении выполнения. Рефакторинг же - упрощение кода в угоду его читаемости. Считать ли сокращение времени на восприятие кода (т.е. затрату человеко-часов) оптимизацией - вопрос открытый к обсуждению. Рефакторинг может приводить к оптимизации потребления, но это не его самоцель, скорее просто сайд-эффект. С этой стороны скорее "реинжиниринг" будет больше походить на оптимизацию, хотя опять же, это не одно и то же. Повторюсь, чисто обывательское мнение.
Оптимизация = правильное применение алгоритмов = ускорение кода; Рефакторинг = читабельность = ускорение разработки и расширяемость. У меня так, пока что, в голове.
В 6ом примере я бы использовал Number() с регулярным выражением, тогда будет не важно, целые числа, есть ли в них буквы или нет, причем когда parseInt/Float уже не справляются:
let regx = /[a-z]/g;
let str = '2.4f';
console.log(Number(str.replaceAll(regx, ""))) //2.4
console.log(parseInt(str)) // NaN
@@TheKorolariya Так это же число, зачем его через регулярно прогонять. Зависит же от ситуации)
Тот мой код это не панацея, чисто чтобы быстро избавиться от грязных чисел, не более)
класс, спасибо
Здравствуйте! 1 пример:
const userRole = `guest`;
switch (userRole){
case `guest`:
case `manager`:
case `affiliate`:
console.log(`Можно`);
break;
}
Как вам это? плохо или хорошо? или лучше switch использовать только тогда когда у нас есть несколько if?
Заранее спасибо за ответы и советы!
разобрался?)
цикл с 3мя элементами запустить дороже чем проверку сделать , уж лучше через битовые маски
а можно потом "в копилочку" видео о деструктуризации сделать?)
можно зделать вот так:
const j = 6;
const h = 7;
но короче :
const j = 6,
h = 7
можно и дальше так делать)))
Первый принцип программиста - главное не навредить)
Первый принцип программиста: работает - не трогай.
@@andrewvasiliev4548 плохого программиста
🙏🏼
Ну по поводу стрелочных функций то вся их прелесть не в сокращении написания кола, а в привязке к контексту :) а писать коротко в одну строку функции часто бывает на много менее читабельно и сложнее для понимания, особенно когда на проекте работает несколько человек.
в switch/case своя область видимости + можно объединить несколько case. Пример некорректный
10:45 "И если он допустим равен нулю" и ставлю 1, тупо краткий портрет программирования когда кто-то наблюдает
Вначале лайк, потом только просмотр. Никак иначе!))
А почему в 5ом примере для читаемости нельзя написать так:
res = typeof t === 'string' ? strCheck(t) : numCheck(t); ?
Вероятно потому что это не читабельно
14:25 это же ключ, а не индекс. Или я ошибаюсь?
Это ключ, да. Дядь Саша оговорился видимо
Превью крутое
На объекте ржал как сука. Советчик епта
😎👍👍👍👍
стрелочная функция не всплывает
НАМЧЕГ
так это ж рефакторинг, а не оптимизация
тут вообще какие-то элементарные вещи, но главное же кликбейтный заголовок
+++
остой полный
Да, в некоторых моментах меня бы уже уволили за такие приколы.