Стиль программирования: на вкус и цвет товарища нет

По условиям контракта языком реализации был стандартный Си. Бельгийцы прислалисвой компилятор ANSI C, но основным рабочим инструментом для нас служил gcc изсистемы GNU, так как он был лучше совместим с нашим любимым отладчиком gdb поформату объектных файлов. Много позже, и это ощущалось нами как внушительныйуспех, мы начали транслировать компилятор самим собой.

Как и полагается каждой солидной фирме, у наших партнеров имелись собственныевнутренние правила и стандарты программирования. В числе необходимых для работыматериалов они привезли нам документ под названием "C Coding Standards".

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

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

Мой коллега принадлежит к следующему поколению программистов, чье взрослениепришлось на эпоху повсеместного распространения мини-машин и, стало быть, напериод повального увлечения UNIXом. Поэтому он впитал дух Кернигана, Ритчи иТомпсона одновременно с базовыми концепциями вычислительной науки и гораздораньше почувствовал себя в этой среде как рыба в воде. Понятно, что онвоспринял все рекомендации и требования фирменного стандарта как нечтоестественное и само собой разумеющееся.

Автор практически полностью пропустил эпоху СМ-ок, пересидев ее в машинном зале"Эльбрусов". Выдающаяся элегантность архитектуры этой системы, ее несомненнаяреволюционность в сочетании с классическими традициями программирования,положенными в ее основу, заставляли относиться к UNIX с легкой иронией?—?как клюбопытной системе с развитым командным языком и с удачным набором небольшогочисла хорошо сочетаемых базовых понятий.

А язык Си показался поначалу чуть ли не студенческой поделкой, сляпанной наскорую руку для себя и друзей, когда уже не было сил программировать наассемблере и BCPL. Да, собственно, и сами создатели языка не слишком скрывалиименно такой первоначальной ориентации Си. Своеобразное изящество, несомненныймагнетизм и подлинная мощь этого языка стали осознаваться (и это оченьинтересно и знаменательно) только при изучении тех новых свойств, которые быливнесены в него создателями Си++. В частности, знаменитая лаконичность Си?—?объект особенно сильной критики его противников?—?показала свою несомненнуюполезность и необходимость для механизма шаблонов. Несомненно, основанная нашаблонах парадигма обобщенного программирования А. Степанова не выглядела бы вСи++ так органично, будь этот язык столь же многословен, как Ада. (СамАлександр Степанов признавался, что его попытка создать STL для Ады провалиласьпрежде всего из-за чересчур «статического» характера этого языка.)

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

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

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

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

Что же касается нелепых или смешных требований, то это во многом действительнодело вкуса и привычек. Что там табуляции?—?в иных стандартах можно встретить ине такое! Например, в каком-то (правда, очень старом) руководстве попрограммированию на Фортране можно было встретить рекомендацию избегатьподпрограмм, так как их вызовы приводят к большим накладным расходам. Акомпилятор GNAT языка Ada95, разработанный в Нью-Йоркском университете, прикомпиляции собственного исходного текста квалифицирует отступление от принятогостиля программирования (например, неверное число пробелов между оператором икомментарием) как… синтаксическую ошибку!

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