Дмитрий Беляев

Анимация = анимации рознь.

Конкретный ответ со списком вы тут не увидите, это будет большая статья, со множественными "а вот тут", "но здесь" просто потому что многое зависит от контекста, задач, планирование.
Главные рекомендации это не делать на js то, что отлично реализуется с помощью css. Этим к сожалению часто болеют многие фронтендеры, особенно из тех кто принципиально не любит вёрстку. Банальные примеры некоторые виды трансформаций объектов при булевых сменах какого параметра(условно навел/убрал наведения, вкл-выкл и тп).

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

Поэтому просто зная возможности css, имея здравый смысл, вы будете видеть и знать где что использовать.
К счастью css тоже в последнее время активно развивается давай нам всё больше возможностей.
Поэтому - простая штука, что-то типа одноразовых анимации, простого повторения, туда сюда - подумать про css.
Если к этому добавляются всякие реакции на сложные тайминги, старт-пауза перемотать остановить на промежутке и тп - js.
Ну и безусловно разные сложные, многоходовки с завязкой друг на друга - однозначно js.

В целом информации на эту тему достаточно в интернете, мудрить здесь особо не стоит. Поэтому повторюсь: просто здравый смысл и держать в уме знание css и не брезговать его использовать. Нередко кстати сами верстальщики уже готовят эти анимации, но это уже отдельный разговор организации команд и внутрипроектной кухни. Я сторонник того что фронтэндер, пусть и не обязан прям верстать верстать, но знать вёрстку/css должен на очень хорошем уровне.

Смотрим исходники (как же там неудобно искать, проще было склонировать и найти в файлах)

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

Описание аргументов ,... это variadic т.е. можно несколько аргументов писать в вызове макроса, они все передадутся как есть (есть разные способы их развертывания)

Вот к примеру твой пример развернется в

static vnet_feature_arc_registration_t vnet_feat_arc_ip4_unicast;
static void __vnet_add_feature_arc_registration_ip4_unicast (void)
  __attribute__((__constructor__)) ;
static void __vnet_add_feature_arc_registration_ip4_unicast (void)
{
  vnet_feature_main_t * fm = &feature_main;
  vnet_feat_arc_ip4_unicast.next = fm->next_arc;
  fm->next_arc = & vnet_feat_arc_ip4_unicast;
}
static void __vnet_rm_feature_arc_registration_ip4_unicast (void)
  __attribute__((__destructor__)) ;
static void __vnet_rm_feature_arc_registration_ip4_unicast (void)
{
  vnet_feature_main_t * fm = &feature_main;
  vnet_feature_arc_registration_t *r = &vnet_feat_arc_ip4_unicast;
  VLIB_REMOVE_FROM_LINKED_LIST (fm->next_arc, r, next);
}
static vnet_feature_arc_registration_t vnet_feat_arc_ip4_unicast

Заметь что последняя строчка не завершена, нет ";", значит если после вызова этого макроса поставить = ... то пойдет определение значения переменной vnet_feat_arc_ip4_unicast
а запись через { .имя_поля=значение,...} это удобный способ инициализировать структуры

instanceof?

Разница в том, что span не несёт никакого семантического смысла, а p несёт и является параграфом.

Лучше так делать не надо. Это UB - нарушение всяких strict aliasing, выравниваия и вообще от порядка байт в машине зависит. Лучше руками собрать ULL по частям, вроде

for (int i = 0; i < 8; ++i) result |= byte_array[i+1] << (8ULL*i);

или

for (int i = 0; i < 8; ++i) result |= byte_array[i+1] << (8ULL*(7-i));

На худой конец, если очень узкое место, надо делать memcpy из массива в &result.

Можешь файл с базой хранить на хостовой машине и монтировать его в контейнер.

Так это вопрос к вам, зачем вы поставили return.
Подозреваю из-за того, что console.log выводила undefined. Так она и должна была его выводить. По условию возвращать ничего не надо, а результат ничего не возвращающей функции как раз undefined.

--  return obj
--console.log( multiplyNumeric(menu) );
++multiplyNumeric(menu);
++console.log(menu);

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

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <title>Пример чтения и вывода текстового файла в HTML</title>
  </head>
  <body>
    <div id="content"></div>

    <script>
      fetch('example.txt')
        .then(response => response.text())
        .then(text => {
          const paragraphs = text.split('\n\n');
          const contentElement = document.getElementById('content');

          paragraphs.forEach(paragraph => {
            const p = document.createElement('p');
            p.textContent = paragraph;
            contentElement.appendChild(p);
          });
        });
    </script>
  </body>
</html>

Добрый день. Я перечитал все ответы выше, а так же комментарии к ним. Решил прокомментировать, с точки зрения своего опыта(я занимаюсь разработкой уже более 15-ти лет). Для удобства чтения я буду писать по пунктам.

1) Зубрёжка. Каждого из нас, кто ходил в школу, заставляли зубрить таблицу умножения. И, в конце-концов, это помогало в последующем обучении математики, не правда ли? В программировании есть такие же вещи, которые называются "стандарты". Вот эти стандарты и нужно, для начала, зазубрить. А позже и вникнуть, зачем они придуманы.

2) Методика "объяснение и практика". Вы пишете, что "при таком способе мне приходится одно и тоже глазами несколько раз пробегать чтобы запомнить". Это, с моей точки зрения, в корне не верно. Ибо то, что вам объясняют, не нужно "пробегать глазами" несколько раз, что бы запомнить. Это вообще не нужно запоминать если это не те самые "стандарты"; это нужно осмыслить и понять. После того, как к вам придёт понимание как это работает, зачем и почему это надо -- вы сможете это использовать, осмысленно, в собственном коде.

3) Платные курсы. Курсы ныне очень разные. Кто-то просто, простите, гребёт бабло на этом всём. А кто-то преподаёт с душой, хорошо и понятно рассказывая. Поэтому платный курс -- это хорошо, но только тогда, простите за тавтологию, когда это хороший курс. Читайте отзывы о курсе, советуйтесь с теми кто его уже прошёл(в идеале) и тогда уже решайте, тот ли этот курс, что даст вам необходимые знания.

4) ВУЗ. Более 10-ти лет назад, у меня в подчинении, в вебстудии, работал PHP джун. Он доучивался в МГТУ имени Баумана. И он не знал ничего. Совсем. Мне приходилось объяснять ему простейшие вещи, типа что значит иструкция "$a += $b;". Сам же я учился в ВУЗе малоизвестном, на факультете "прикладная информатика в экономике" и наш преподаватель информатики, на первом курсе, на вопрос что значит в коде программы на языке C++ инструкция "с++" ответил, что это "так язык называется". Однако, вскоре ко мне начали ходить сокурсники, с просьбами "а напиши программку". И происходило это потому что я сам загорелся программированием, купил книжки, установил всё что нужно было установить на компьютер и начал "творить волшебство", как это мне тогда виделось, с горящими глазами. Короче говоря не нас учат ВУЗы, а мы учимся в ВУЗах или учимся без них. Тут уж как пойдёт.

5) Ну и последний, самый важный, с моей точки зрения, пункт. Это Интерес. Если вам интересно программирование, вам нравится разбираться, что-то делать самостоятельно, а не только тогда когда кто-то поставил задачу, то у вас все получится. И как именно это всё учить у вас вопроса, в конце концов, не возникнет. Разбирайтесь, ковыряйте, вникайте и всё будет. Единственное что -- очень желательно, что бы перед вашими глазами были хорошие примеры. Потому что я, в свое время, тоже разбирался, учился и вникал, "гладили по голове", как писали выше в комментариях к одному из ответов, меня уже мои наниматели, потому что я все делал быстро и без ошибок, т.е. работало все так, как было нужно клиентам веб-студии, собеседование в которую я тогда прошел без каких-то проблем. Но вот мой код тогда был, откровенно говоря, тем, что сейчас называется "говнокодом". Потому что некому было мне показать как писать есть хорошо, а как есть плохо.

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