Приемы JavaScript, которые ухудшают качество кода

0 0

Следовательно, знание глубины языка очень важно. Люди ненавидят JS, потому что они не понимают его полностью и то, как он работает под капотом. Более того, некоторые люди думают, что знают его, но в конечном итоге следуют некоторым методам, которые, в свою очередь, ухудшают качество кода проекта. Следовательно, наша задача сегодня — обсудить те практики, которые приводят к подобной ситуации.

Все еще пользуетесь var?

Неужели? Вы все еще этим занимаетесь? Мы находимся в наиболее созидательных годах, которые переживает мир JS. С такими фреймворками, как React или Angular, правящими рынком, вы используете то, что устарело 6 лет назад. Если вы не работаете над чем-то очень старым, этой ситуации нет оправдания.

Для того чтобы резюмировать, давайте посмотрим, что такое var и почему лучше использовать let и const. Когда вы объявляете ключевое слово var, его область действия не ограничивается блоком, внутри которого оно находится. Значение var доступно в любом месте за пределами блока. Вы, должно быть, уже поняли ситуацию, когда у нас могут возникнуть проблемы. Если нет, то вот пример.

Приемы JavaScript, которые ухудшают качество кода

Приемы JavaScript, которые ухудшают качество кода

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

В этой ситуации мы не получим ошибки, но вместо этого наше значение будет переопределено. Возможно, это не та ситуация, которую мы желаем. С let и const у нас не будет такой ситуации. JS Engine выдаст синтаксическую ошибку.

Использование непонятных имен

При изучении JS можно использовать const a = «value». Но использование таких методов будет болезненным для вас и других разработчиков, когда вы будете работать над каким-либо проектом. Поверьте мне в этом. Мы в Groww преподаем это как самый первый обучающий проект. Допустим, вы написали следующий код.

Приемы JavaScript, которые ухудшают качество кода

Удалось ли вам понять, что означают эти константы и где они будут использоваться? Может быть. Потому что вы это написали. Но поймут ли это ваши коллеги? В отличие от приведенного выше кода, ниже приведен лучший вариант.

Приемы JavaScript, которые ухудшают качество кода

Понятно, что означают наши переменные. Следовательно, используйте интуитивно понятные имена переменных.
Использование ‘==’ вместо ‘===’.

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

Приемы JavaScript, которые ухудшают качество кода

Для тех, кто знает разницу между undefined и null, описанная выше ситуация может быть волшебной. На самом деле, чем меньше магии в вашем коде, тем он лучше.

Приемы JavaScript, которые ухудшают качество кода

‘==’ просто сравнивает значения, не учитывая их типы. Этот сценарий может временно избежать ошибок, но ваш код может работать хуже, если сравнивается что-то неожиданное. Следовательно, на всякий случай всегда используйте ‘===’. Это своего рода строгое сравнение, в котором сравниваются как значения, так и их типы. Наш благоприятный результат для приведенных выше утверждений:

Приемы JavaScript, которые ухудшают качество кода

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Приемы JavaScript, которые ухудшают качество кода

Незнание принципа DRY в кодировании

Это не связано с самим JavaScript. Просто стандартная практика кодирования, которой вы должны следовать на любом языке при программировании. Принцип DRY означает «не повторяйся». Я думаю, это не требует пояснений. Мы должны стараться изо всех сил писать чистый код минимальным количеством слов. Простой пример:

Приемы JavaScript, которые ухудшают качество кода

Кажется, намного лучше, правда? Это всего лишь пример. Попробуйте отыскать такие примеры в своем коде и найдите для них новаторские решения.

Не обрабатывать ошибки в вызовах API

Если вы работаете над средними или крупными проектами, скорее всего, вы работаете с API. Независимо от того, используете ли вы Fetch, Axios или даже XHR, всегда есть вероятность отказа API по любой причине. Это может быть «не авторизовано», «не найдено» или «общая ошибка сервера».

Не только новички, но даже некоторые опытные ребята забывают учитывать эти ситуации, что не очень хорошо для пользовательского опыта. Обработка ошибок делает ваше приложение менее подверженным нежелательным ситуациям.

Непонимание функций Arrow и Normal

Я знаю, что большинство из вас знакомы со стрелочными функциями. Но ограничены ли ваши знания лишь тем фактом, что они являются синтаксическим сахаром для обычных функций? Если это так, то вам многого не хватает. Между ними есть очень существенные различия, игнорирование которых может привести к неприятностям.

Стрелочные функции не имеют собственного контекста. Это особенно важно, если они определены внутри другой функции. Например, как обратный вызов для выполнения forEach. Если внутри стрелочной функции вы используете ключевое слово this, вы ссылаетесь на контекст родительской функции. Это большая разница, потому что перед стрелочной функцией вам нужно будет сохранить ссылку this перед вызовом функции обратного вызова, а в обратном вызове использовать новую ссылку, иначе, внутри, this будет иметь совершенно новый контекст.

Стрелочные функции не являются допустимыми конструкторами. Вы не поверите — обычные функции «конструктивны». Это означает, что их можно вызывать с ключевым словом new и возвращать новый экземпляр этой функции. Почему это возможно? Потому что тогда, до ES6, у нас также было прототипное наследование в качестве основного способа работы с объектами, а функции (обычные функции) были для них конструктором. Однако теперь с классами это больше не является «подходящим вариантом», и стрелочные функции отражают это изменение. Стрелочные функции, хотя и вызываемые (как и обычные), не могут быть конструктивными, поэтому вы не можете поставить new перед их вызовом, это не сработает.

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

Использование старых приемов

Поскольку мы создаем все более и более сложные варианты использования с JavaScript, это заставляет нас, как разработчиков, иногда использовать уловки, чтобы наш код продолжал работать. Классический пример — поиск, содержит ли массив элемент. Мне никогда не нравилось использовать array.indexOf(item) !== -1 для проверки наличия предмета.

Это могло бы работать нормально, но это не очень хороший способ. Мы должны быть в курсе последних версий ES6 и более новых стандартов. Они привносят новые функции для эффективного решения наших проблем. Например, в приведенной выше ситуации мы можем использовать новый метод ES6 array.includes(item). Это всего лишь один пример. Может быть бесчисленное множество других.

Это были некоторые из вещей, которые, как мне кажется, следует учитывать при написании лучшего кода JavaScript.

Автор: Tushar Sehwag

Источник: webformyself.com

Оставьте ответ