8.2.3. Использование рисунков

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

Использование графического представления при решении задач полезно всегда, однако похоже, что в Прологе оно работает особенно хорошо. Происходит это по следующим причинам:

(1) Пролог особенно хорошо приспособлен для задач, в которых фигурируют объекты и отношения между ними. Часто такие задачи естественно иллюстрировать графами, в которых узлы соответствуют объектам, а дуги — отношениям.

(2) Естественным наглядным изображением структурных объектов Пролога являются деревья.

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

8.3. Стиль программирования

Подчиняться при программировании некоторым стилистическим соглашениям нужно для того, чтобы

• уменьшить опасность внесения ошибок в программы и

• создавать программы, которые легко читать, понимать, отлаживать и модифицировать.

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

8.3.1. Некоторые правила хорошего стиля

• Предложения программы должны быть короткими. Их тела, как правило, должны содержать только несколько целей.

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

• Следует применять мнемонические имена процедур и переменных. Они должны отражать смысл отношений и роль объектов данных.

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

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

• Оператор отсечения следует применять с осторожностью. Если легко можно обойтись без него — не пользуйтесь им. Всегда, когда это возможно, предпочтение следует отдавать "зеленым отсечениям" перед "красными". Как говорилось в гл. 5, отсечение называется "зеленым", если его можно убрать, на затрагивая декларативный смысл предложения. Использование "красных отсечений" должно ограничиваться четко определенными конструкциями, такими как оператор not или конструкция выбора между альтернативами. Примером последней может служить

если Условието Цель1иначе Цель2

С использованием отсечения эта конструкция переводится на Пролог так:

Условие, !. % Условие выполнено?

Цель1;      % Если да, то Цель1

Цель2       % Иначе - Цель2

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

• Внесение изменений в программу при помощи assert и retract может сделать поведение программы значительно менее понятным. В частности, одна и та же программа на одни и те же вопросы будет отвечать по-разному в разные моменты времени. В таких случаях, если мы захотим повторно воспроизвести исходное поведение программы, нам придется предварительно убедиться в том, что ее исходное состояние, нарушенное при обращении к assert и retract, полностью восстановлено.

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

Для иллюстрации некоторых положений данного раздела рассмотрим отношение

слить( Спис1, Спис2, Спис3)

где Спис1 и Спис2 — упорядоченные списки, а Спис3 — результат их слияния (тоже упорядоченный). Например:

слить( [2, 4, 7], [1, 3, 4, 8], [1, 2, 3, 4, 4, 7, 8] )

Вот стилистически неудачная реализация этого отношения:

слить( Спис1, Спис2, Спис3) :-

 Спис1 = [], !, Спис3 = Спис2;

  % Первый список пуст

 Спис2 = [], !,  Спис3 = Спис1;

  % Второй список пуст

 Спис1 = [X | Остальные],

 Спис2 = [Y | Остальные],

 ( X < Y, !,

   Z = X, % Z - голова Спис3

 слить( Остальные1, Спис2, Остальные3 );

 Z = Y,

 слить( Спис1, Остальные2, Остальные3 ) ),

 Спис3 = [Z | Остальные3].

Вот более предпочтительный вариант, не использующий точек с запятой:

слить( [], Спис, Спис).

слить( Спис, [], Спис).

слить( [X | Остальные1], [Y | Остальные2], [X | Остальные3] ) :-

 X < Y, !,

 слить(Остальные1, [Y | Остальные2], Остальные3).

слить( Спис1, [Y | Остальные2], [Y | Остальные3]): -

 слить( Спис1, Остальные2, Остальные3 ).