> Мне кажется что эти требования малость взаимоисключающие: чем меньше рож (и автоматики) смотрит в код тем больше предпосылок для того чтобы он хреново и ненадежно работал.Вы не совсем поняли сарказм. Я про скроллинг мышкой, как писали выше - если предполагаемые сопровождающие не умеют пользоваться иде для навигации по коду и для них надо разбивать код на отдельные файлики, то... остается только сочувствовать.
Само собой, если код состоит из независимых частей, то его можно и разбить на независимые файлы. Но если это виртуальная машина (или там, как я выше запостил, драйвер 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К упихана, чтобы совсем не скучно было? :)
Вы еще и документацию попросите каждую главу в отдельный файлик закинуть.. Для полного, так сказать, погружения.
...остальное отдельно...
