> Мне кажется что эти требования малость взаимоисключающие: чем меньше рож (и автоматики) смотрит в код тем больше предпосылок для того чтобы он хреново и ненадежно работал.

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

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

А от количества файлов качество кода не зависит никак. Вообще никак.

> Э? Я думал это про сишный код? Чего в нем макакам надо?

Как будто их и в С мало..

> Понятно, заец-маздаец.

Эммм. Вы, вероятно, не в курсе - но vscode отлично работает под линуксом.
`Linux xxx 4.15.0-89-generic #89-Ubuntu SMP Fri Feb 14 xx:xx:xx UTC 2020 x86_64 x86_64 x86_64 GNU/Linux`

И на данный момент это лучшая иде для работы с сишным кодом.

> И даже более того - человеков не больно то и возьмется. И вообще такие прожЕкты через раз дохнут после того как Основной Мега Кодер утратил, дескать, интерес.

Вы не поняли. Это не пет-проджект, не фрисорс и не поделия мамкиных хакиров. За это платят деньги, причем немаленькие. И этот проект уже лет 5 не требует никакого обслуживания: он отлично написан, отлично документирован, отлично саппортится (если, конечно, сначала прочитать хотя бы часть прилагаемой документации и иметь соответствующие скилы - например, в деталях знать алгоритмы сборки мусора).

>> Но даже если бы я ее разломал на 100 кусков по 500 строк, это бы только ухудшило ситуацию.
> С чего вдруг? При этом еще на уровне иерархии было бы видно в какой примерно кус мы хотим. Что, наверное, делает это более дружественным к окружающим. Хотя если копание окружающих в коде не упало - это, конечно, вариант.

Я уже писал - код виртуальной машины. Главное требование - скорость и надежность работы.
Там (вот только не плюйтесь) есть огромный switch, при этом часть кейсов не заканчивается брейком, а переходит на следующие. Разбивать это на функции с передачей части параметров по двойному указателю, выносить в отдельные компилируемые единицы и ждать чуда, что компилятор это все красиво заинлайнит, раскроет и сохранит скорость работы - совершенно безнадежно, что и было протестировано и доказано.

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

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

> А эта документация тоже в те 50К упихана, чтобы совсем не скучно было? :)

Вы еще и документацию попросите каждую главу в отдельный файлик закинуть.. Для полного, так сказать, погружения.

...остальное отдельно...