ну давай, напрягись

Я напрягусь и пойду дальше поработаю, а вам оставлю время подумать и почитать

то, что несколько патчей ревью не прошло не опровергает моего утверждения, что патчи с багами ревью прошли в ядро попали.

я боюсь представить результаты твоей работы...

Сочувствую борьбе с проявлением байкшеддинга.

К сожалению, в кровавом энтерпрайзе принято всё до крайности доводить - и это совсем не техническая проблема.

Но регулярное ревью - это круто. Даже в одном и том же проекте видно, что фичи, которые по той или иной причине проходили формальное ревью или не проходили - гораздо хуже реализованы, чем те, которые проходили...

Например, в драйверы radeon и nouveau недавно были приняты изменения с вызовом pm_runtime_put_autosuspend(dev->dev) в блоке ошибки, не исключено, что приводящему к использованию буфера после освобождения связанной с ним памяти.

но нашлись также патчи с ошибками.

Что ядро. Все мы помним, как несколько лет назад коммит чувака с 0 других коммитов на GH мало того, что попал в OpenSSL, так ещё и дошёл до этапа эксплуатации уязвимости (HeartBlead)

а еще у дебиановцев была история

когда они энтропию почистили

или это про неё?

Это отдельная история

Ну давайте из-за пары гнилых яблок в ведре откажемся от остальных

никакой там "явной магии" не написано - обыкновенные pack/unpack и сдвиги. А комментарии описывают ровно то, что написано самим кодом, типа "делаем сдвиг". Подобного образа комментарии обычно требуют преподы, проверяя, что студент действительно понимает, что за операторы он применил, т.к. язык еще толком не знает. В промышленном коде такой комментарий дублирует сам код, и не нужен - в комментариях должно быть написано не "что" делает код (это им самим видно), а "почему". А на это - с натяжкой! - годится разве что последний из трех комментариев примера

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

Ну как это не важно, там выше один умняш предлагал писать реальное финансовое по с использованием флоатинг поинт. Это верное архитектурное решение :)

начал за здравие, а кончил за упокой. Количество комментариев зависит не от качества программистов, если только ты не вчерашних студентов понабрал, а от сложности кода и/или [говнистости] предметной области, которую он представляет.

Вот пример, https://github.com/nuclight/tkxgram/blob/master/emojtextst.pl#L190 - до 190-й строки комментариев ты практически не увидишь, там и так всё понятно. Зато дальше идёт блок, где комменты подробно описывают, какого хера тут такая мутотень. А потом до конца - снова особо без комментов

плюсую

"Магия" в том, что в обычном коде таких сдвигов и работы с байтами не встречается. А по поводу того, что комментарии тут недостаточно хороши, я уже написал.

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