После внимательного прочтения предлагаемых соглашений о кодировании на фирму было послано длинное эмоциональное письмо с подробным анализом стандарта и выводами, смысл которых заключался в архаичности и немотивированности большинства его требований и норм. Не буду воспроизводить все критикуемые нормы, скажу только о таком требовании, как представлять последовательности пробелов, которые используются для формирования отступов, непременно символами табуляции. Может быть, это как-то и оправдано для среды UNIX, в которой мало удобных и гибких текстовых редакторов, и символ табуляции практически всегда отображается на экране восемью пробелами, Однако на персоналках любой мало-мальски приличный текстовый редактор можно настроить на представление табуляции любым числом пробелов. Поэтому следование этому правилу на практике приводит к тому, что один и тот же текст будет выглядеть в различных средах совершенно по-разному. Невозможно перестраивать редактор под каждый файл с табуляциями.
Ответ был очень интересным. Поблагодарив, как водится, за интерес и внимание к документу, они ответили на каждый тезис моего письма. Возражений по существу не было вообще. Однако не было и согласия на отмену или изменение ни одного из критикуемых требований. Поначалу такое умолчание привело меня в бешенство. Истинный смысл такого странного ответа стал понятен намного позже.
Дело в том, что даже плохой стандарт лучше его отсутствия. Стандарт может быть устаревшим, неполным, содержать недостаточно обоснованные требования, но, тем не менее, крайне важно, чтобы все разработчики ему следовали. То обстоятельство, что вся программная продукция фирмы сделана по единым правилам, гораздо важнее в долгосрочном плане по сравнению с тем, что эти правила произвольны или несовременны. Общие правила (наряду с другими мерами) делают программу отчуждаемой от конкретного разработчика, давая возможность, скажем, сопровождать и развивать ее даже в случае отсутствия того, кто ее написал.
Поэтому допустить отступления от правил даже в одном проекте, пусть в большом и сложном (в моем письме без лишней скромности говорилось, что такой проект достоин отдельного стандарта), фирма, конечно, не могла. И проявленная ими реакция на запальчивые, при всей их обоснованности, аргументы в пользу модернизации стандарта говорит только о мудрости фирмачей, за плечами которых опыт многих проектов.
Что же касается нелепых или смешных требований, то это во многом действительно дело вкуса и привычек. Что там табуляции — в иных стандартах можно встретить и не такое! Например, в каком-то (правда, очень старом) руководстве по программированию на Фортране можно было встретить рекомендацию избегать подпрограмм, так как их вызовы приводят к большим накладным расходам. А компилятор GNAT языка Ada95, разработанный в Нью-Йоркском университете, при компиляции собственного исходного текста квалифицирует отступление от принятого стиля программирования (например, неверное число пробелов между оператором и комментарием) как… синтаксическую ошибку!
Так что и этот опыт тоже не прошел для нас даром. Следующий проект, в котором мы участвовали, начался именно со спецификации требований на стиль программирования (получился текст объемом более полусотни страниц), и особое внимание было обращено на то, чтобы все программисты ему следовали.
Программирование "наизнанку"
Решающим фактором в том, что сегодня мы имеем нечто, что можно с уверенностью назвать компилятором Си++, стало тестирование. Нам трудно судить о том, как следует тестировать, скажем, текстовый редактор или (упаси, Господи!) операционную систему, но наш опыт тестирования и отладки компилятора говорит о том, что это едва ли не самое главное во всем проекте.
Нам очень повезло. Кроме компилятора, бельгийцы заказали еще и пакет тестов на проверку компилятора (любого, не только нашего) на соответствие стандарту. Этот пакет мы и натравили на наш компилятор, точнее, на то, что мы тогда считали таковым.
Нам повезло и в том отношении, что пакет делала другая команда. Два опытных специалиста, давно занимавшиеся проблематикой тестирования именно компиляторов, на этом еще в прежние времена защитившиеся, придумали методику разработки тестов и написали формальные спецификации, а группа студентов по этим спецификациям выдавала сами тесты.
Надо понять специфику этой работы, чтобы оценить ее невероятную сложность. Есть стандарт языка (который и не стандарт вовсе, а "рабочие материалы по предварительному стандарту рабочих групп ANSI и ISO", и почти каждый квартал выходит новая версия этих "рабочих материалов"). Это кирпич в три килограмма. Каждый абзац стандарта содержит одно утверждение (а чаще несколько) относительно того или иного свойства языка. Тестовый пакет должен проверять каждое такое свойство, т. е. содержать соответствующий тест на каждое утверждение стандарта. Каждое утверждение тестируется в предположении, что другие языковые свойства компилятор реализует корректно,-- протестировать все сочетания свойств физически невозможно. Предварительный стандарт, как уже говорилось, постоянно изменяется, значит каждый новый талмуд нужно просмотреть и увидеть, что изменилось по сравнению с прежним (перечень изменений рабочие группы не ведут), и внести в тесты соответствующие изменения и добавления.
Далее, текст стандарта написан, как и полагается, невероятно сложным, занудным, бюрократическим языком. По-другому нельзя, так как в стандарте требуется предельная точность, но попробуйте это перевести и понять! Примеров программ очень мало, и некоторые нужно разбирать так же, как разбирается сложная фраза на чужом языке — слово за словом. Это ни в малейшей степени не похоже на учебник по языку — никаких пояснений, никакой специальной методики изложения, никакого принципа "от простого к сложному", в любом месте текста может встретиться ссылка на термин, вводимый далеко впереди.
Наконец, предварительный стандарт — это текущий результат живых дискуссий, обсуждений, голосований рабочих групп; там сидят очень грамотные специалисты, но и они ошибаются и не все сразу видят. Поэтому в каждой версии есть (и в окончательном варианте будут) ошибки, неясности, двусмысленности, недоговоренности. Все это присутствует, наверное, в любом стандарте, но Си++ в этом отношении чемпион — слишком это сложный язык и слишком хаотически и спонтанно он проектируется. Так что, читая стандарт, следует четко осознать, почему та или иная фраза кажется тебе абракадаброй: то ли ты плохо знаешь английский, то ли недостаточно глубоко понимаешь Си++, то ли ребята из ANSI/ISO что-то напутали (а часто и то, и другое, и третье). И не с кем посоветоваться — все учебники по Си++ излагают в лучшем случае версию "Зеленой книги" 1990 г.,-- и нельзя проверить свое понимание на компьютере: нет компилятора, который реализовывал бы свойство, за которое комитет проголосовал на прошлой неделе. Еще не отлита та пуля…
В таких условиях и был написан тестовый набор, который в итоге содержал более 6500 тестов. (Можно понять, почему подобные пакеты стоят на Западе до 20 тыс. долл.!) Важно то, что до определенного момента две наши команды работали полностью независимо, никак не влияя друг на друга. В результате тесты не подгонялись под компилятор, а алгоритмы компилятора проектировались строго по семантике языка, без ориентации на то, чтобы протолкнуть его сквозь конкретные тесты. Взаимные консультации касались только обсуждения собственно текста стандарта — отправной точки для обеих групп. Только когда компилятор в основном был сделан, мы начали использовать тесты из него.
Вообще, создание тестового пакета — отдельная история, не менее интересная и драматичная, чем наша. На самом деле далеко не все было так гладко и последовательно, как описано выше. Наш шеф В.А.Сухомлин потратил очень много усилий на формирование коллектива тестовиков. Можно понять сложность задачи — непросто найти программистов, которые хотели и могли бы заниматься "программированием наизнанку" — использовать язык не для решения какой-либо задачи, а для проверки того или иного свойства самого языка! Авторы методики тестирования довольно быстро выполнили свою задачу и, не будучи знатоками Си++, отошли от проекта. Руководить той адовой работой по написанию тестов, о которой мы писали выше, пытались разные люди, но только с приходом Дениса Давыдова, аспиранта мехмата, процесс приобрел систематический и продуктивный характер. У этого одаренного и трудолюбивого парня была масса очень интересных и действительно перспективных находок и идей, связанных с тестированием ПО, и если бы не его совершенно необъяснимая и неожиданная кончина, вся эта работа сейчас наверняка выглядела бы еще сильнее и солиднее. Талантливые люди всегда уходят слишком рано…
