Главная » Информационные системы » Технология программирования » 12. Требования к стилю программирования (оценки модульности, структурности)

12. Требования к стилю программирования (оценки модульности, структурности)

СТИЛЕВЫЕ КОНФЛИКТЫ И ОЦЕНКИ СТИЛЯ ПРОГРАММИРОВАНИЯ

Чичев Александр Алексеевич, Чекал Елена Георгиевна

Ульяновская государственная сельскохозяйственная академия (УГСХА), г.Ульяновск :D:D

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

Язык программирования — это язык. И в нем, также как в обычном языке, определены алфавит, лексика, синтаксис и т.д., то есть, определены некоторые правила построения фраз (операторов), используя которые, человек может общаться на этом языке с другими людьми (и даже с ЭВМ!). Констатируется, что каждый человек, знающий некоторый язык (умеющий читать на этом языке и писать на этом языке), также имеет некоторый стиль, который является характерным для данного человека и который проявляется, когда человек пишет на этом языке, например, программу.

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

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

Крайне желательно для насаждения красивого стиля программирования использовать в качестве примеров программы, разработанные гуру программирования. Образцы программ, как правило, поставляются в виде example в составе систем программирования. Для языков Си, С++ очень хорошими примерами являются системные программы среды UNIX, в частности, LINUX.

Дополнительно в процессе обучения могут быть использованы

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

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

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

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

Везде далее, где написано процедура, следует читать процедура (функция).

1.Оценка модульности программы

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

Модульность программы подразумевает, что программа разбита на процедуры разумной длины, каждая из которых выполняет некоторую функцию, определяемую алгоритмом программы. При определении длины процедуры будем учитывать только операторы самой процедуры, в терминах Паскаля — блок Begin-End. Внутренние (вложенные) процедуры будем считать самостоятельно, как отдельные процедуры.

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

Оценим среднюю длину процедуры как отношение суммы длин всех процедур, включая блок main, к количеству всех процедур, включая блок main.

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

2.Оценка структурности кодирования

Будем учитывать требования структурного кодирования суммированием штрафных баллов по каждому случаю нарушения:

  • оператор GOTO используется для выхода из процедуры — 5 баллов;
  • оператор GOTO используется для перехода назад по программе — 2 балла;
  • другие случаи использования оператора GOTO (выход из цикла вперед по программе, использование в условном операторе) — 1 балл;
  • наличие в строке более одного оператора — 0,25 балла;
  • процедуры не отделены друг от друга строками комментария (минимум две строки комментария на процедуру) — 1 балл;
  • текст программы не сформатирован, т.е. не используются сдвиги вправо для обозначения блоков программы — 5 баллов;
  • отсутствуют начальные блоки комментариев в процедурах — 3 балла;
  • не комментированы циклы, условные операторы, операторы END (операторы ; для Си), операторы перехода — 0,25 балла;
  • метки GOTO (а также метки оператора format для Фортрана) определены не в возрастающем порядке — 1 балл;
  • перекрытие GOTO — диапазонов — 3 балла;
  • метки оператора format (для Фортрана) расположены в диапазоне GOTO — 1 балл;
  • глубина вложенности условных операторов и операторов циклов не превышает 10; каждый уровень вложенности сверх указанного — 0,5 балла.

Оценка структурности кодирования определяется как сумма штрафных баллов.

Здесь необходимо предусмотреть веса для параметров для того, чтобы сумма баллов всегда была меньше, либо равна 100.

3.Оценка структурированности

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

4.Оценка читабельности

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

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

1)Структура программы выдержана:

  • Начальный блок комментария.
  • Объявления (констант, типов, переменных, внешних процедур, внутренних процедур).
  • Внутренние процедуры.
  • Блок begin-end.
  • Штраф — 1 балл.

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

3)Константы, типы и переменные описаны в комментариях. За каждый неописанный случай — штраф 0,1 балла.

4)Текст отформатирован: логические блоки выделены сдвигами операторов вправо — 0 баллов.

Нарушение — 0,05 балла, но в сумме не более 3 баллов. Грубые нарушения данного пункта:

  • все операторы набиты с первой колонки — 3 балла;
  • книжный текст: сверхплотное расположение операторов (по несколько операторов на каждой строке) — 3 балла.

5)Процедуры отделены друг от друга двумя строками комментария — 0 баллов, одной строкой — 1 балл, комментарий отсутствует — 2 балла.

6)Более одного оператора на строке; за каждый случай — 0,1 балла.

7)Все логические блоки (операторы if, case, switch, goto, exit, операторы циклов и т.д.) прокомментированы — 0 баллов. Невыполнение требования — 0,25 балла.

8) Прокомментированы операторы end /* чего? */ (для языка Си — ;).

Невыполнение требования — 0,1 балла.

9)Комментарии располагаются сбоку (справа) от исполняемых (комментируемых) операторов, а не расположены с ними вперемежку.

Невыполнение требований — до 0,5 балла.

10)Если переменные используются в программе для нескольких целей — 1 балл. Если случай перенацеливания не комментирован — дополнительно — 0,5 балла за каждый случай.

11) Использование булевских переменных (типа BOOLEAN): true — включено, false — выключено; если переключатель моделируется переменной другого типа, то аналогично, 1 — включено, а 0 — выключено. За каждое нарушение — 1 балл.

12)Если алгоритм программы формирует во входной области программы особые точки, то это прокомментировано. Невыполнение требования — 3 балла.

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

Невыполнение требования — до 1 балла.

14)Программа удовлетворяет требованию структурированности (см. п.3). Оценка выполнения требования в баллах равна трёхкратной оценке структурированности.

Необходимо предусмотреть веса для параметров для того, чтобы общая сумма баллов была всегда меньше либо равна 100.

Пусть общая сумма набранных баллов равна b. Тогда оценку читабельности программы определим как разность между 1 и отношением b к 100.


Друзья! Приглашаем вас к обсуждению. Если у вас есть своё мнение, напишите нам в комментарии.

Поделиться

Дисциплины