13.3. Стиль программирования и запись программ

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

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

В качестве имени предиката мы выбираем слово (или несколько слов), описывающее взаимосвязь между объектами программы, а не действия выполняемые в программе. Придумать удачное декларативное название процедуры сложнее.

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

Мнемонические имена переменных также влияют на простоту чтения программы. Именем может быть некоторое содержательное слово (или слова) или стандартная форма, такая, как Xs для обозначения списков.

Переменные, входящие в предложение лишь однократно, могут быть помечены особым образом. Их можно рассматривать как анонимные, и с точки зрения реализации их именование излишне. В некоторых версиях языка Пролог придерживаются специальных синтаксических соглашений в обозначениях анонимных переменных. Например, в Edinburgh-Прологе для этой цели используется отдельный символ подчеркивания. С использованием такого соглашения программа 3.12, задающая отношение member, будет иметь такой вид:

member(X,[X | _ ]),

member(X,[ _ | Ys]) member(X,Ys).

Достоинство этого соглашения состоит в том, что явно выделяются переменные, унификация которых существенна. Недостаток связан с достоинством - правило понимается процедурно, а не декларативно.

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

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

fоо(<Аргументы>) 

bar(<Аргу менты>),

bar(<Аргументы>).

.

.

.

bar(<Аргументы>).

Заголовки всех предложений выравнены, цели в теле предложений записаны с отступом, каждая цель занимает отдельную строку. Процедуры отделяются пустыми строками, но между отдельными предложениями одной процедуры пустые строки не используются.

Размещение программ в книгах и при типографском оформлении не вполне следует этим правилам. Если все цели в теле правила невелики, то они записываются в одной строке. Иногда мы используем таблицы фактов, записывая в одной строке более одного факта.

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

На практике текст программы часто нуждается в дополнительных пояснениях. Одной из существенных частей документирования является построение реляционных схем. Реляционная схема приводится перед предложениями, описывающими отношение, и при необходимости снабжается дополнительными разъяснениями. Разъяснения, приводимые в данной книге, описывают вычисляемое процедурой отношение. Записать на естественном языке ясное декларативное определение отношения, вычисляемого логической программой, иногда не так просто. Однако неспособность написать такое определение обычно свидетельствует о том, что программист сам не вполне понимает, что же он разработал, хотя его программа действительно работает. Поэтому мы призываем использовать принятые в данной книге правила документирования. Эти правила предоставляют удобное средство разъяснить смысл программы. Кроме того, они дисциплинируют мышление, помо­гают программисту анализировать и описывать собственные разработки.