Добавляет доку "Базовые операторы в JS"

[anton-fomichev]

Описание

• Добавит нового автора в /people/anton-fomichev
• Добавит первую версию статьи. Включает в себя:
  • описание терминов "оператор" / "операнд"
  • типы операторов
  • математика
  • работа операторов с объектами
  • приоритет операторов
  • присваивание
  • инкремент и декремент

Closes #5077

Чек-лист

• Текст оформлен согласно руководству по стилю
• Ссылки на внутренние материалы начинаются со слеша и заканчиваются слэшем либо якорем на заголовок (/css/color/, /tools/json/, /tools/gulp/#kak-ponyat)
• Ссылки на картинки, видео и демки относительные (images/example.png, demos/example/, ../demos/example/)

[anton-fomichev]

Нужна помощь с заполнением полей keywords и related. В ходе работы наткнулся на следующие страницы в Доке:

• Почти всё в JavaScript — объект
• Преобразование типов

Мне кажется, что они хорошо подходят на роль кандидатов в related

[vitya-ne]

Привет, спасибо за доку!
Вернусь к более внимательному прочетнию в ближайшее время )

[github-actions]

Превью контента из f3008a9 опубликовано.

[Inventoris]

Привет Антон!

Очень круто, спасибо, что сделал для Доки этот чудесный материал ƪ(˘⌣˘)ʃ

Я всё посмотрел, есть несколько глобальных комментов:

1. Материал большой, развёрнутый, добротный. Это уже не дока, а статья. Поэтому нам нужно оформить её, как статью. Вот полезная документация на тему. Я бы предложил такую структуру:
   • Что за операторы?
   • Кто такие «оператор» и «операнд»? (туда можно поместить про унарные и бинарные операторы, чтобы не плодить главы).
   • Далее главы по каждому типу операторов. Мне нравится, как ты сделал "математика" и "не только математика". Можно, например, присваивание, математика, сравнение, побитам, строки. Давай попробуем объединить всё в простые главы. Что не относится к типам операторов, можно выделить в отдельные.
2. Главу "как делать не надо" и подобные штучки помещаем в раздел "На практике". Там ты с величины своего опыта советуешь что делать, как делать итд. Очень хорошо, если туда что-то набирается. Вот тут инструкция.
3. Дока пишется с объяснениями на пальцах буквально. Тут я помогу, но в целом просьба взглянуть на текст с позиции "йоу, чуваки, щас я вам расскажу, что это за грибы такие". Сильно тут не напрягайся, я оставлю комментарии позже или подредактирую с твоего позволения сам. В целом ничего критичного, текст читается весьма легко =)
4. Начали с того, что рассказываем про базовые операторы, а получился большой материал почти про все. Это хорошо. Давай то, чего не хватает по теме, добавим. Чтобы были все операторы. И сделаем из материала именно не "Базовые операторы в JS", а просто "Операторы".

Итого:

• Допиливаем структуру глав.
• Добавляем "На практике".
• По возможности упрощаем. Например, из "В JavaScript у операторов есть определённый порядок выполнения" можно сделать "Операторы выполняются по очереди". Если сложно, сделаю сам.
• Добавляем нехватающих операторов, чтобы получился гайд по всем операторам. И так и называем статью, "операторы".

Если где-то сложно или нужна помощь, маякуй, я приду) У нас получится развёрнутый материал - статья про операторы в JS с лаконичным простым текстом. Красота!

[anton-fomichev]

@Inventoris
Мне казалось, что идея в том, чтобы делить статьи на несколько уровней (базовые/углубленные/узкоспециализированные), чтобы направлять аудиторию сразу в нужное место и лучше продвигаться в поиске, например.

Но если делать какую-то общую статью, то как, например, быть с отдельными статьями:

• Тернарный оператор,
• Логические операторы.

И если делать, то в каких рамках хотелось бы остаться внутри этой статьи?

Note

Тут забавный факт, что изначально я писал именно статью, но её предложили переделать в доку. Из-за этого материала получилось довольно много, хочется просто понять к какому результату хотим прийти в конечном итоге :)

[Inventoris]

@Inventoris Мне казалось, что идея в том, чтобы делить статьи на несколько уровней (базовые/углубленные/узкоспециализированные), чтобы направлять аудиторию сразу в нужное место и лучше продвигаться в поиске, например.

Но если делать какую-то общую статью, то как, например, быть с отдельными статьями:

• Тернарный оператор,
• Логические операторы.

И если делать, то в каких рамках хотелось бы остаться внутри этой статьи?

Note

Тут забавный факт, что изначально я писал именно статью, но её предложили переделать в доку. Из-за этого материала получилось довольно много, хочется просто понять к какому результату хотим прийти в конечном итоге :)

Да, факт забавный =) Но думаю ты был прав изначально. Всё таки хорошая структура документации, это когда есть большая обзорная статья со всем, но кратко, для ознакомления и быстрого поиска инфы, а также отдельные статьи уже более углубленные.

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

Тут стоит применить такой же подход. Делаем большую статью, но с краткой инфой по операторам, советами итд, ёмко. Не разрастаемся, оставляя пространство для будущих материалов с подробностями по каждому оператору отдельно.

[nasty23-star]

Привет! Большое тебе спасибо за классный материал!<3
Написала небольшое предложение, посмотри, пожалуйста, вдруг идея понравится.
Апрув!

[nasty23-star]

Может быть, второе слово "разработчик" убрать? мне кажется, по контексту понятно, что речь идёт о разработчике.