Введение

Программирование - это еще один вид сверхдержавы, но, как сказал дядя Бен своему племяннику Питеру Паркеру, “С большой силой приходит большая ответственность”. В мире программирования наша самая большая ответственность заключается в том, чтобы гарантировать, что код, который мы пишем, легко тестируется и будет поддерживаться с течением времени.

Есть некоторые практики в программировании (bad practies), которые могут оказывать постоянное негативное влияние на код, который мы пишем, и на продукт, который мы создаем в качестве конечного результата. Я столкнулся с этими проблемами не понаслышке и хочу рассказать, что это такое, и почему вам следует избегать их любой ценой.

1. Использование var вместо const и let

Вы должны использовать только let и const по этим причинам:

• Блочная область видимости.

• Не создают глобальные объекты.

• Нельзя пересоздать переменную с тем же названием.

2. Использование комментариев для объяснения кода

Комментарии являются фундаментальной частью, когда мы создаем любое ПО, они помогают нам немного лучше понять код, который мы читаем, но не надо объяснять, что делает каждая строка нашего кода, мы должны создавать код, который легко читается, а комментарии должны только обеспечивать контекст.

Вот несколько советов и напоминаний, которые помогут вам писать комментарии к коду как профессионалы:

• Избегайте избыточности в своих комментариях; не пишите, что вы делаете, пишите, почему вы это делаете.

• Сжимайте комментарий как можно больше; не пишите абзацы, если в этом нет крайней необходимости.

• Старайтесь всегда использовать один и тот же язык и стиль комментариев.

• Со временем комментарии обычно не поддерживаются (модифицируется) код.

3. Использование == вместо ===

Первое, что нужно понять, это то, что, хотя визуально они очень похожи, они делают разные вещи: первый называется обычным оператором сравнения (==), а второй называется оператором строгого сравнения (===).

Обычный оператор сравнения (==) проверяет только то, похожи ли операнды, что может вызвать некоторые неприятные сюрпризы.

Оператор строгого сравнения (===) всегда проверяет, что они в точности одинаковы: имеют одинаковый тип и значение.

4. Не использование оператора опциональной последовательности

В оригинале optional chaining => оператор опциональной цепочки, на MDN же я нашел другую формулировку данного оператора и решил использовать именно её.

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

Это помогает нам избежать ошибок при попытке получить доступ к несуществующему свойству. В качестве примера предположим, что у нас есть объект Pokémon, который содержит информацию об этом покемоне.

Когда мы хотим получить доступ к свойству, которое не определено, например, в этом примере, доступ к свойству attack Javascript вызовет ошибку, и наше приложение выйдет из строя. При использовании опциональной последовательности (?) Javascript сообщит нам, что свойство не определено, но не сгенерирует никакой ошибки.

5. Использование магических строк и чисел

Под магическими имеется ввиду непонятные числа / строки, смысл существования которых понимает только человек, который написал этот код. (И то не всегда)

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

6. Неправильная обработка ошибок при работе с API

Если мы не будем обрабатывать ошибки в наших промисах (promises), очень вероятно, что наше приложение взорвется, и поверьте мне, мы не хотим, чтобы это произошло.

7. Использование объекта в качестве единственного параметра

При объявлении функции, в которой от объекта ожидается несколько значений, лучше всего использовать несколько входных параметров вместо входных данных одного объекта (деструктуризация).

Это помогает нам в нескольких вещах:

• облегчает чтение нашего кода, поскольку мы с самого начала знаем, какие параметры нужны вашей функции.

• облегчает тестирование функции.

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

Еще одним плюсом является то, что если вы используете TypeScript и у вас есть несколько параметров, проще определить интерфейс параметров, чтобы воспользоваться проверкой типов и автоматическими предложениями, что позволяет нам избежать ошибок.

8. Не использование сокращений

Мы все были в положении, когда задавались вопросом, существует ли переменная или содержит ли она какое-то значение, отличное от null или undefined. Из-за этого мы часто заканчиваем тем, что выполняем сверхдлинные проверки такого типа:

Сокращения помогают нам избежать этой проблемы. Более простым и элегантным способом приведенный выше код может быть сведен всего к следующему:

if (x) { ... }

В оригинале автор использует if (!!x), но, насколько мне не изменяют мои знания основ логики, двойное отрицание = исходное значение.

Заключение

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

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

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

Как обычно, буду рад любому фидбеку, а если вы нашли ошибку - напишите в лс или комментариях.

Только добра.