Как фронтенд-инженер, 10 полезных методов кодирования JavaScript, которые вы должны использовать

Обязательно освойте эти навыки.

Предисловие

Раньше я писал много ненужного кода, а теперь это выглядит ужасно.

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

Итак, вот 10 советов по JavaScript, которые помогут вам избежать написания ненужного кода, который когда-то делал я.

1. Обещайте ад обратного звонка

Промисы — это элегантный способ обработки асинхронных операций в JavaScript. Это также одно из решений, позволяющих избежать «ада обратных вызовов». Но я не совсем понял, что это значит, поэтому написал этот фрагмент кода.

Я сделал следующие вещи:

1. Сначала получите основную информацию о пользователе.
2. Получите краткую сводку всех статей по пользовательской информации.
3. Получить детали статьи через статьи кратко.

Я вообще не использую Promise. Мы должны обрабатывать это, как фрагмент кода ниже:

2. Не обрабатывать сообщения об ошибках

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

Это неопытно, и мы должны дать удобную подсказку вместо того, чтобы ничего не делать.

3. Установка слишком большого количества параметров для функции.

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

Пример

Мы хотим получить базовую информацию о пользователе, такую ​​как имя, пол, возраст, и т. д..

Это ужасно. Если ваш коллега напишет такой код, вы его побьете?

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

4. Магическое число

Друзья мои, вы когда-нибудь писали такой код? Кажется нормальным использовать числа для вынесения логических суждений во многих местах. Да, меня смущает, что именно означают 1, 2, 3.

Мы лучше определим эти числа как константы.

5. Использование .length для оценки длины строки

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

Когда мы набираем 🍫, значение nameLen равно 2 — не странно ли это?

Да, на то есть причина, угадайте какая?

6. Никогда не пишите комментарии к коду

Мы часто жалуемся другим: «Почему вы не пишете комментарии к коду?» Но на самом деле, я никогда не пишу это!

Боже мой, вы знаете, что означает «dpr»? Я никогда не думал, что это означает window devicePixelRatio。

7. Бессмысленные комментарии к коду

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

С тем же успехом вы могли бы объяснить, что означает «а», или использовать осмысленные имена переменных!

8. Случайное наименование

Раньше я писал неуклюжие фрагменты кода со случайными именами переменных.

Друзья, не учитесь у меня. Вы должны дать переменным правильное и осмысленное имя.

9. Не удаляйте устаревший код

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

На самом деле, это беспокойство совершенно излишне, потому что вряд ли оно будет использовано в будущем. Даже если он будет использоваться в будущем, его можно отследить через «git».

10. Более тысячи строк кода компонента

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

Окончательно

Спасибо, что прочитали. Я с нетерпением ждувашей подписки и новых качественных статей.

Дополнительные материалы на PlainEnglish.io.

Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord .

Заинтересованы в масштабировании запуска вашего программного обеспечения? Ознакомьтесь с разделом Схема.