Программы надо писать так, чтобы они были понятны другим
(С) СК Пресс 11/95Споры о том, как писать программы, казалось бы, утихли. Казалось бы, все ясно. Но по-прежнему многие молодые люди ухитряются писать плохо.
У англичан есть один замечательный обычай, вернее, правило хорошего тона: когда вежливый человек отправляет письмо кому-то малознакомому, он пишет его печатными буквами. Это ни в коей мере не воспринимается как оскорбление - адресат, мол, человек малограмотный и "по-письменному" не разбирает. Вопрос о том, кому тратить лишнее время - пишущему (на вырисовывание букв) или читающему (на разбор почерка) - решается в пользу читающего. Кстати, один мой знакомый уверял, что каллиграфический от природы почерк (если речь идет о мужчинах) - безошибочный признак психических аномалий носителя. Описанный обычай утвердился очень давно и даже нашел свое отражение в языке, так что, если вы увидите на англоязычной анкете просьбу "Please, print", не воспринимайте ее буквально и не начинайте сдувать пыль с пишущей машинки или подгонять интервалы на принтере. Глагол "to print" означает, кроме прочего, еще и "писать печатными буквами", т. е. разборчиво.
Во время прошедшей в середине осени этого года выставки SofTool, как всегда, проводились "Софтулийские игры" - состязание по блицпрограммированию. Участники должны были за ограниченное время (на мой взгляд, слишком ограниченное) сделать что-то при помощи компьютера. Задание, подготовленное редакцией PC Magazine/Russian Edition, требовало составить программу на языке Си для решения достаточно сложной задачи: подготовить программу - администратор файлов с интерпретатором команд на естественном русском языке. Впрочем, условия задачи были поставлены в достаточно общей форме: словарь не менее 8 слов (максимум не ограничивался), а сложность подмножества грамматики, которое будет реализовано, определяет автор программы, чтобы соискатели призов могли сами для себя решить, насколько полным и исчерпывающим станет предлагаемое решение.
Никто не ожидал, что найдется такой гений, который решит эту сложнейшую проблему в более или менее полном объеме за два часа. Его и не нашлось. Автор этих строк поставил первый эксперимент на себе и обнаружил, что почти все отведенное время ушло у него на одно только обдумывание, что делать и как. Наверное, я слишком много знаю...
Честно говоря, результаты конкурса вызвали преимущественно разочарование. Прежде всего очень многие из молодых людей, которые посчитали себ готовыми к участию в конкурсе, отнеслись к заданию "по-студенчески": если есть выбор - делать побольше или поменьше, - выбирается второй вариант. Они готовили не интерпретатор естественного языка, а обычный интерпретатор командных строк с русскими командами.
Но не это самое худшее. Оказывается, я иду не в ногу со временем. Мне казалось, что к моменту перехода на объектно-ориентированный стиль программировани структурное программирование уже стало единственным способом писать программы (объектно- ориентированные программы тоже должны быть структурированными, хотя и по несколько иным правилам). В самом деле, среди тех, кто преподает программирование, уже практически нет людей, которые считали бы структурные конструкции чем-то избыточным. Но очень многие из конкурсантов составляли свои программы в самом дурном стиле, который я считал давно отошедшим в прошлое. И это несмотря на то, что в задании было в явном виде указано: программа должна быть понятна не только своему автору и компилятору! Как же это получается? Кто учит молодых людей писать плохие программы? А я то идеалист, думал, что научиться дурному стилю программирования в наше время просто негде.
На мой взгляд, как это ни покажется парадоксальным, виноват... язык программирования Паскаль. Это действительно замечательный язык, который завоевал всеобщее признание и в качестве учебного, и как рабочий - для тех, для кого программирование - не основное занятие в жизни. На Паскале почти невозможно составлять неструктурированные программы. Этим он выгодно отличается от Си. И вот молодые ребята, готовящиес стать профессионалами, переключаются с Паскаля на Си, приходят в восторг от вновь открывшихся возможностей и начинают их где надо и где не надо использовать. Вносят свою лепту и иные преподаватели, которые интерпретируют программирование так же, как математику. В математике каждая теорема считается самоценной, практически никогда студентам не рассказывают, для чего эта теорема потребуется в дальнейшем. Да это и очень трудно. Но программирование - дисциплина сугубо практическая. Однако профессоры доказывают основную теорему структурного программирования - о том, что всякий конечный алгоритм можно разложить на структурные блоки - в лучших традициях академического стиля. В мозги слушателей внедряется мысль о том, что это можно сделать, но не говорят, зачем это нужно.
Да извинят меня специалисты за тривиальные с их точки зрения мысли. Я считаю себя обязанным восполнить пробел и рассказать читателям, для чего требуетс структурное, равно как и выросшее из него объектно- ориентированное программирование. Программы пишутся не для компьютеров, а для людей. Человеческие возможности, как это ни печально, ограниченны. У всякого человека есть максимум информации, которую он в состоянии охватить как единое целое. И структурное, и объектно-ориентированное программирование позволяют расчленить программу на относительно небольшие модули, каждый из которых можно рассматривать независимо или почти независимо от остальных. Таким образом удаетс резко уменьшить число ошибок, упростить отладку и т. д. Кроме того, современное программирование - занятие коллективное. В ваших модулях волей-неволей должны будут разбираться другие, да и вам может потребоватьс через год или два, когда задача уже будет давно забыта, вернуться к своей программе. Один из наиболее важных критериев качества программы - ее обозримость. Текст должен быть таким, чтобы его могли понять другие программисты, не обращаясь за разъяснениями к автору, и чтобы не приходилось изобретать машину времени, если программу перечитывает сам автор. Хотелось бы добавить одно соображение "на перспективу". Ученые уже достаточно давно работают над методами автоматической проверки правильности программ. Совсем не исключено, что уже при жизни современного поколения программистов эти методы будут доведены до практической реализации. И тогда, по крайней мере на первых порах, программу придется составлять так, чтобы она была доступна дл проверки при помощи другой программы. То есть структурно. Пока этого от нас не требуют, но привыкать стоит.
Еще один совет. Избегайте рассматривать ассемблерное представление своей программы, составленной на языке высокого уровня. Самая структурированная программа на Си после трансляции на язык ассемблера превращается в кошмарное нагромождение "макаронных" кодов с выходами за пределы внутренних вложенных блоков, с не поддающимися никакому обозрению цепочками условных и безусловных переходов, с данными, перемешанными с исполнимыми кодами самым причудливым образом, и прочими прелестями.
Я не пурист. Жизнь неоднократно вынуждала мен отступать от строгих принципов построения программ. Но опыт научил всякий раз в этих случаях писать программу "печатными буквами", чтобы любой человек мог ее понять за вполне разумное время. Будьте вежливы. И не только по отношению к компьютеру.