Назад | Содержание | Вперёд

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 | Остальные],
                ( Х < Y,  !,
                Z = X,                           % Z - голова Спис3
                слить( Остальные1, Спис2, Остальные3 );
                Z = Y,
                слить( Спис1, Остальные2, Остальные3 ) ),
                Спис3 = [Z | Остальные3].

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

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

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

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

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

8. 3. 2.    Табличная организация длинных процедур

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

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

8. 3. 3.    Комментирование

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

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

• Что программа делает, как ею пользоваться (например, какую цель следует активизировать и каков вид ожидаемых результатов), примеры ее применения.
• Какие предикаты относятся к верхнему уровню?
• Как представлены основные понятия (объекты)?
• Время выполнения и требования по объему памяти.
• Каковы ограничения на программу?
• Использует ли она какие-либо средства, связанные с конкретной операционной системой?
• Каков смысл предикатов программы? Каковы их аргументы? Какие аргументы являются "входными" и какие - "выходными", если это известно? (В момент запуска предиката входные аргументы имеют полностью определенные значения, не содержащие не конкретизированных переменных.)
• Алгоритмические и реализационные детали.

Назад | Содержание | Вперёд