>>19736

>Переменные делать осмысленными это хорошо, но тривиально.

Но во-первых, речь не только о осмысленных названиях, и во-вторых, осмысленные названия и адекватное форматирование увеличивают размер кода. В условной конструкции можно встретить длинное условие, наполненное однобуквенными переменными. Замена однобуквенных переменных нормальными однозначно сделает строку длиннее, но понятнее. Но неожиданно одних имен не достаточно для хорошей читабильности, необходимо ввести пояснительные переменные, которые неожиданно добавят в код новых строк. В данном примере абсолютно закономерное и оправданное увеличение через тривиальные действия, которое делает код лучше и понятнее. 60 строчек было изначально и от того, что строк 60, он не становился яснее. Одного добавления имен не хватило бы, чтобы сделать код понятнее. Требовалось детальное изучение. Для пояснения намерений, отдельные блоки кода надо было тоже как-то заименовать. Естественно, по итогу стало больше 60ти строк. Если бы код рефакчил Мартин Фаулер, их тоже стало бы значительно больше. Ты из раза в раз повторяешь "60 строк в 14", как будто это прям без вариантов плохо.
По поводу состояния, то, что оно должно быть едино, то, что оно не может принадлежать разным уровням абстракции, это твоя личная оценка, которую ты не поясняешь. А в чем проблема, если мы изначально ставим цель разделить единое сложное на простые части, чтобы при работе с одним аспектом программы, мы не должны были отвлекаться на чтение других аспектов? В чем проблема, что состояние разделилось на части по задачам, которое оно выполняет? В этом же и весь смысл и изначальная цель. Естественно, выделение абстракций и извлечение классов мешает видеть всю реализацию сразу и целиком, потому что это противоположная цель.
Вот у нас была куча не пойми чего, которая делает не пойми что. Вот у нас теперь класс PrimeGenerator, который внезапно генерирует пример, есть RowColumnPagePrinter, который рсует колонки с этими примерами и PrimePrinter. Нахрена им быть едиными и не разбивать состояние?

>Стена текста, в которой суть - "хорошо пишите, плохо не пишите".

А за что ты топишь, писать плохо? Стиль Боба это не только сказать "пишите хорошо", но в первую очередь о том, "что такое хорошо, и что такое плохо". Если книга отвечает на "что-вопрос", значит она добилась цели. Обычно критика предполагает, что Боб не правильно указал, что плохо, а что хорошо. Когда же критик в целом согласен по пункту "что хорошо", и даже на этой основе предъявляет самому Бобу претензии, то цели и содержания Чистого кода такой критик никак не отменяет. Если к самим рекомендациям Боба претензий нет, то доебывания, что он сам их не везде соблюдает, мне не интересны т.к. это опровержение нихера не опровергает. Как и оценочные обобщения с продавцами юдеми. Не говоря уже о том, что Боб оговаривается, что здесь не все чисто.

>непоследовательности

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