Очень интересно и полезно :)) Спасибо Вам!!!

Очень полезное видео. Спасибо!

Чистый код - спокойный сон!;) Как всегда, спасибо!

Коротко чётко и ясно =) Респект бро 🥇

Ясно, чисто, понятно. Должно стать привычкой для каждого.

Отличная инфа, спасибо!

все четко и по делу, прям не к чему придраться! Я бы давал ссылку на данный видос девелоперам как эталон хорошего кода :)

Good job 👏

Более полная информация из видео Оригинал на Анг: github.com/ryanmcdermott/clean-code-javascript Перевод на русский: github.com/ryanmcdermott/clean-code-javascript

3:14 я бы тут поспорил, длина имени переменной напрямую зависит от времени ее жизни(величины контекста) => "l" отлично подходит, вот если бы у тебя стрелочная функция состояла строк так из 10 и больше, тогда уместно было бы использовать "location"

9:15 может показаться что геттеры и сеттеры нужно использовать всегда, я сначала так и подумал) Это справедливо для языков типа php, c# или java. Но в js можно их добавлять тогда, когда будет нужно

Отличное видео.

Хорошие советы, спасибо. Единственное, что бросилось в глаза: функция isActiveClient (kzfaq.info/get/bejne/jrpmi856r6-6knU.html) далеко не такая простая, как может показаться из её названия. Выглядит как функция, которая «залезет» в переданный объект и проверит одно-два поля; но на самом деле реализация «идёт» в базу за записью и проверяет уже полученные из базы данные. С separation of concerns и single-responsibility principle у этой конкретной функции не очень.

thank u

5:08 - как по мне, версия, обозначенная "Bad", читается куда легче и она решает одну конкретную задачу - выполнение email для всех активных пользователей. Дальнейшая декомпозиция излишня. Кроме того, когда тебе дают чужой проект на 120 файлов, хрен найдёшь этот isActiveClient, его наоборот надо компоновать, а не разбивать. Главные принципы декомпозиции в том, чтобы: - метод был читаем, - были понятны зависимости, - описание всего метода помещалось на одном экране Остальное - это прихоти. 6:19 - Как раз при масштабировании и надо пристыковывать дополнительные функции, вместо внедрения дополнительной логики в первичную. Например есть у вас функция валидации формы. Изначально в ней были только текстовое поле, поле телефона и область текстового ввода. И вы изначально сделали просто одну проверку телефона. Добавилось у вас поле mail и вот тут надо не пихать свитчкейс в функцию валидации, а вынести проверку телефона и mail в отдельные функции, пристыковав их к первичной. И не надо писать отдельную функцию для получения введённых данных, ссылаясь на SRP. Это самый простой пример. 6:52 - Отрицаний бояться - в логику не лезть. Всегда старайтесь писать условие так, чтобы then был короче else, если else предполагается. Конкретно в этом примере Bad не потому, что отрицание в условии, а потому, что функция возвращает значение, которое для наличия then нужно инвертировать. Сам пример говорит о том, чтобы не допускать двойного отрицания.

5:05 мне верхний Bad код кажется более понятным чем второй.

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

лучше записывать const MILLISECONDS_IN_A_DAY = 24 * 60 * 60 * 1000

Да, всё это норма.

5:30 "Не используйте флаги как аргумент функции". Goog не делает то же самое что Bad. Собственно пропущена функция проверки. А когда она будет написана, она будет вызывать две функции и передавать им аргумент имя. Который надо иметь в той же области видимости, что и флаг. И так мы ничего не выигрываем (ну кроме двух названий функций, что часто бывает хорошо, но речь шла не об этом)

А про html закончился курс или будут еще видео?

извините,но звук на заднем фоне сильно мешает(

7:10 - создавать дополнительный интерфейс вместо сигнатуры функции - ошибка по бритве Оккама. Не вижу проблемы для линтеров указывать на неиспользуемые аргументы, кроме того, линтеры могут указать на недостаток аргументов при использовании этой функции. И не могут этого сделать при передаче всех аргументов как свойства объекта

У этих правил литературная основа? Это из книги или из опыта?

Делайте, пожалуйста, музыку на фоне тише, а то мешает воспринимать информацию)

на каком языке эти примеры?

Может быть я не оч хороший знаток JS, но чет пример на 10:59 - нифига не строитель.

правило что функция должна делать только одно действие - ну кто это придумал? )))))))) сначала себе напридумывают правил, потом страдают.