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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Данный текст является ознакомительным фрагментом.