Никак не отпустит тема влияния усреднения на качество кода в частности и программного обеспечения в целом.

Постулаты

Сначала постулаты, без принятия которых дальше читать смысла нет.

Во-первых, самый эффективный в исполнении код ― код, созданный с учётом особенностей машины исполнения (как железной, так и виртуальной). Яркий пример из общей практики: Data alignment: Straighten up and fly right. Что занятно, в мире Java тоже следует иногда учитывать DA: JVM Anatomy Quark #24: Object Alignment.

Во-вторых, люди не просто разные, они очень разные. Постулат кажется очевидным и тривиальным, пока не встречаешь заявления типа «да никто это не поймёт», «да никому это не надо», «сейчас все пишут на Go» и т.п. Если вы относитесь к любителям подобных фраз, уходите, читабельность кода точно даже в первую сотню проблем вашей жизни не входит.

Методы повышения readability

Что такое readability (читабельность)? Комплекс мер, применяемых с целью сокращения пути от точки A («я ЭТО увидел») до точки Z («я ЭТО понял»). В интересах эссе я разделю эти меры на два класса:

  • объективные ― улучшают восприятие кода 99 безымянными программистами из 100;
  • субъективные ― улучшают восприятие кода Васей и Петей.

Объективные

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

Самый понятный пример: форматирование и раскраска визуализируют структуру текста, подчёркивают его смысл.

Печалька:

class Test { public static void doSomething() { System.out.println("Hello"); }}

Не печалька:

class Test {
    public static void doSomething() {
        System.out.println("Hello");
    }
}

Или вот разбиение кода на смысловые блоки (абзацы).

Печалька (код безумный, да):

class Test {
    public static final boolean BAD_CODE = true;
    public String doSomething() {
        int a = 0;
        String s = "";
        for (int i = 10; i > a; i--) {
            s = s + i;
            System.out.println(s);
        }
        return s;
    }
}

Не печалька:

class Test {
    public static final boolean BAD_CODE = false;

    public String doSomething() {
        int a = 0;
        String s = "";

        for (int i = 10; i > a; i--) {
            s = s + i;
            System.out.println(s);
        }

        return s;
    }
}

Больше Java-примеров вот тут: Google Java Style Guide

Или, скажем, простота ключевых слов ЯП.

Мы все умрём:

weltschmerzfuhrer Test {
    borschtzch gebrakkulten doSomething(gebrakkulten a) {
    	zuklatzklatz a + a;
    }
}

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

Субъективные

А вот дальше в ход идёт понимание текста, что топит тему в болоте субъективности. Почти всё в этом классе порождено тем, что НЕКТО чего-то не понял. Не смог. Не осилил. Этих нект может быть много, но всё же не настолько много, чтобы прекратить называть их по именам и переходить на уровень «всех программистов». Так вот, правила здесь появляются по следующему шаблону:

  • Ивановы не осилили X;
  • X объявляется опасным и заодно менее читабельным;
  • отрицание X впиливается в массовые мануалы;
  • два-три поколения Ивановых и даже намёк на использование X вызывает «НИКТО ТАК НЕ ДЕЛАЕТ! НЕЛЬЗЯ! ХАРАМ!».

Наглядными считаю два примера.

GOTO. В 1968 году Дейкстра опубликовал небольшое эссе под названием Go To Statement Considered Harmful (PDF), чем набросил на вентилятор на десятилетия вперёд:

For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce. More recently I discovered why the use of the go to statement has such disastrous effects, and I became convinced that the go to statement should be abolished from all “higher level” programming languages (i.e. everything except, perhaps, plain machine code). At that time I did not attach too much importance to this discovery; I now submit my considerations for publication because in very recent discussions in which the subject turned up, I have been urged to do so.

Как в то время, так и в наше (один из примеров разбора: Go To Statement Considered Harmful: A Retrospective) эссе Дейкстры состоит из кучи спорных утверждений (начиная уже с первого абзаца), полемика была знатная, но массы Вась и Джонов подхватили самое простое: не использовать goto. Вот враг. Если микроскопом фигово забивать гвозди, надо выкинуть микроскоп, вот тогда заживём. То, что под капотом никуда goto (от технических джампов в машинных кодах до семантических ветвлений и переходов в современных языках) не делся, никого не волнует, лишь бы дети спичками не играли.

Prepostindecrement. Васи и Джоны не могут в -- и ++. Это слишком сложно. Потому выпилить из Swift (Remove the ++ and -- operators), из JavaScript (Disallowing Unary Increment and Decrement (++ and --)), из Go (proposal: Go 2: remove ++ and -- operators), ну и вообще. Я прям рандомно набрал то, что под руку попалось. Просто поверьте: этому уже много лет. В Python так и вовсе не завезли, чтобы студенты не страдали.

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

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

Кому понятный код

И вот тут самое время спросить: что такое понятный код? Может ли понятность кода оцениваться без учёта читающего? Понятный КОМУ код?

Это стихотворение «Рассвет» Хуана Рамона Хименеса.

El viento rinde las ramas
con los pájaros dormidos.
— Abre tres veces el faro
su ojo verde —. Calla el grillo.

¡Que lejos, el huracán
pone, uno de otro, los sitios!
¡Que difícil es lo ficil!
¡Que cerrados los caminos!

Parece que se ha trocado
todo. Pero al claror íntimo
se ven arenas y flores,
donde ayer tarde las vimos.

Я не понимаю этот текст. Возможно, потому, что он на испанском языке, а я не знаю испанского. Если твёрдой рукой натянуть аналогию на мир программирования, получится интересное:

  • это плохое стихотворение, т.к. я его не понял;
  • часть символов я знаю, но некоторые мне неизвестны, давайте их уберём;
  • лучше вообще убрать испанский язык, чтобы Хименес писал на русском понятном мне языке;
  • я объективен ― десятки миллионов людей не знают испанский язык, это не только я такой;
  • фигня непонятная какая-то; я знаю испанский («хей, мучачос, цвай пивас, пор фавор!»), а здесь автор выдалбывается, лол;
  • я десять лет в трюме под испанским флагом по морям ходил, все эти слова не нужны, якорь тебе в турбину!

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

Не получается ли так, что в стремлении писать понятный код мы пишем плохой код только потому, что этот код будет (быть может) читать кто-то, у кого ну совсем фигово с испанским? И вместо «Рассвета» Хименеса загнаны в рамки деревенской поэзии:

с неба падали розы
вот такие у нас грозы
в речку лотся чя-то кров
вот така у нас лубов

Любой Вася может дописать и переписать (ого!). И это тоже поэзия! Круто же получилось. Отличное стихотворение. Убрано всё, что смущало и мешало писать тексты (дурацкая непонятная пунктуация, избыточные большие буквы, аще фиг знает зачем нужные ‘ё’ и ‘ю’, мягкий знак заманал путаться с твёрдым!). Хоть сейчас в продакшен. Вот теперь это ПОНЯТНЫЙ КОД.

То, что Хименес писал неделю, я написал за минуту. Испанский не нужен.

Маё время дялозе любова камплютира.

Так что не так-то?

Опасной считаю совокупность причин и последствий.

Во-первых, вместо инженерной дисциплины программирование превращается в олимпиаду творцов. Чем дальше, тем более многим непонятным становится код, включающий в себя элементы «железа», «теории», «матана». Этот код не понимают люди, вошедшие в разработку через заднюю дверь, да так в проёме и застрявшие. Филолог, садящийся за клавиатуру, хочет написать сделай_мне_красиво и нажать Enter.

Во-вторых, повторю, речь идёт про сокращение доступного программисту инструмента. Как если бы у меня из ящика убрали крестовую отвёртку потому, что толпа Петровых регулярно себе в ухо по рукоять загоняет. А спичек нет потому, что Сидоров поджигает ими себе задницу.

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

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

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

В-шестых, сдвигается… как бы сказать. Фигня в том, что не специалист растёт, но выражаемые понятия (алгоритмы, конструкции, идеи) опускаются. И вот такое направление начинает считаться правильным. Вполне обычно уже прочитать в обсуждениях фразы типа «за такое в коде надо увольнять» (один чувак, вроде даже не птенец вчерашний, отреагировал на [Henry S. Warren. Hacker’s Delight]). Как по мне, увольнять надо за такие фразы, но это ни фига не модная точка зрения.

В-седьмых, как ни крути, но компьютеры работают не на сонетах Шекспира. Из какого ополчения набирать контрактных профессионалов, что будут писать задники сделай_мне_красиво? На каком коде воспитываются ополченцы? Смогут ли миллионы примитивных строк кода заронить хотя бы в одного из десяти тысяч то зерно, из которого в будущем появится чувак, создающий ядра операционных систем? Мне кажется, сложно самому стать Есениным, если вместо Пушкина тебя всё время пичкают лубочными частушками.

Всё плохо

Да, всё плохо. Я, конечно, сгустил краски, всё не плохо-плохо, но просто плохо. И будет ещё хуже.

Однажды мы проснёмся, а все компьютеры мира с трудом выполняют одну строчку на PythonJS: Helo warld. Ну или не выполняют, но будут блокчейново обмениваться семью миллиардами зависимостей, требуемых для выполнения этой строчки. К вечеру обменяются. Зато как красиво будет написана эта строчка!