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

Одно из правил - буквально слово в слово - я недавно встретил в одном популярном эссе о написании кода без ошибок (я расскажу об этом правиле позже). Мне стало любопытно, насколько применимы остальные правила со школьного плаката (короткий ответ – да), и есть ли у этого обоснование. Я немного зарылся в литературу, и вот что понял.

Программный код с точки зрения лингвистики

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

Ну вы поняли, да?

С точки зрения лингвиста любой язык программирования – это просто еще один язык, такой же, как китайский или наскальные петроглифы. Он отражает внешний мир во всей его сложности и многообразии, но в полезном для человека виде. Со своей семиотикой, правилами, синтаксисом и даже фонетикой. Но подчиняется он тем же самым объективным законам лингвистики, ведь он творение рук человеческих.

Для лингвиста текст программы – это набор символов, который несет законченную мысль. Такая мысль называется инвариантом текста (научное определение элемента абстрактной системы языка в отвлечении от ее конкретных реализаций). А вот конкретный набор операторов программного языка в программе – называется его токенами (да, гуманитарии употребляют этот термин с 1980-х годов XX века ).

Вот возьмем, к примеру, код на С:

x = a + b * 2;

Лексический анализ этого выражения дает следующую последовательность токенов:

[(identifier, 'x'), (operator, '='), (identifier, 'a'), (operator, '+'), (identifier, 'b'), (operator, '*'), (literal, '2'), (separator, ';')]

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

Если вы согласны с вышеуказанным, то нам остался всего один шаг.

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

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

Don’t write bugs

Мы все хотим писать код без ошибок. Мы все любим писать код без ошибок. Ошибки в коде - это плохо, и, чаще чем хотелось бы, это дорого. Если вы написали код с ошибкой, то хорошо, если это просто потеря личного времени и небольшой удар по нашему самомнению. Но ведь они приводят и к вполне осязаемым экономическим потерям (время на исправление и тестирование, репутация, даунтайм сервиса, потерянные клиенты).

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

Но что, если рассмотреть программный код с точки зрения простых правил лингвистики, которые были написаны на плакате в кабинете литературы - вот эти правила (по памяти):

1. Пойми то, о чем хочешь написать

2. Поняв, структурируй свою мысль

3. Структурировав, напиши мысли простыми словами

4. Написав, перечитай вслух то, что написал.

Давайте разберем каждое правило с точки зрения написания безошибочного программного кода.

Пойми то, о чём хочешь написать

Даже великие программисты временами забывают, что «писать код» и «понимать, что ты делаешь» - не одно и то же. Когда учительница литературы просила «раскрыть тему сочинения», она имела в виду ровно то же самое, что и архитектор ПО, когда говорит «разберись в бизнес-логике». Если вы не поняли задачу, вы не напишете работающий код - вы напишете фанфик на тему «Как я представляю себе HTTP-запрос».

На каком-то уровне мастерства программирования вы уже будете писать грамматически выверенные программы (а где-то будут помогать IDE, компиляторы и линтеры). Но неопределенность в предметной области всегда будет источником ошибок. Просто потому, что мы всегда моделируем реальность с определенной степенью погрешности.

Классическое обсуждение этого вопроса содержится в статье Серебряной пули нет (No Silver Bullet, 1986) Фредерика Брукса. В ней Брукс подчёркивает разницу между побочной сложностью (англ. accidental complexity) и имманентной сложностью (англ. essential complexity) и утверждает, что «ни в одной технологии или в управленческой технике не существует универсального метода, увеличивающего на порядок производительность, надёжность и простоту» (так называемой «серебряной пули»). Он прямо говорит - сложность программ - не в языке и не в синтаксисе, а в понимании сущности задачи.

Это и есть первый пункт плаката: сначала пойми, о чем ты хочешь написать свой код.

Поняв, структурируй свою мысль

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

Дейкстра в своём ��егендарном эссе Structured Programming писал, что хаотичный поток инструкций мешает человеку рассуждать о корректности программы. Структура - это не просто синтаксис, это инструмент понимания.

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

Структурировав, напиши мысли простыми словами

В литературе есть золотое правило: если можно сказать проще - скажи проще. Тот же принцип в коде известен как KISS (Keep It Simple, Stupid).

Когда мы пишем код, нас нередко тянет показать, какие мы умные. Но код - это не соревнование по синтаксическим трюкам, а инструмент общения. Хороший код должен быть понятен даже тому, кто будет читать его через три года (то есть тебе же, но уже с седыми висками).

# Было
result = list(filter(lambda x: x if x not in exclusions and (x % 2 == 0 or x % 3 == 0) else None, data))
# Стало
result = [x for x in data if x not in exclusions and (x % 2 == 0 or x % 3 == 0)]

Первое - будто школьник написал сочинение, используя весь словарный запас. Второе - лаконично и понятно. Это не лучший код, но все же шаг вперед к понятному, а значит безошибочному, коду.

Если хотите почитать дальше, то рекомендую статью Пиши простой код.

Написав, перечитай вслух то, что написал

Это, наверное, самое простое и важное. И это единственный совет по улучшению кода из статьи Don't write bugs.

Учительница заставляла нас читать написанное не просто так. Когда мы произносим текст, мы начинаем слышать его шероховатости. Кент Бек в Clean Code говорил, что хороший код «читабелен как проза». Если вы можете проговорить строку кода и не сбиться с дыхания - вы на правильном пути. Если ваш код «скрипит на слух» - значит, что-то не так.

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

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

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

Заключение

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

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