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

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

Стандартизация стиля – правило: если сущ более одного способа сделать что-то и выбор произволен, то остановиться на одном и способе и всегда его придерживаться. Делая одно и тоже всегда одинаково легче избежать путаницы, однако процессу стандартизации свойственны и недостатки т.к. применение стандартов может замедлить работу, стандарты могут оказаться огранич или громоздкими для написания. Станд стиля – результат здравого смысла и опыта программистов, а не закреплённое раз и на всегда правило.

Комментарии – их редко вставляют в прогу, но потом авторы понимают что не помнят программу. Хорошее правило – включать комментарии в процессе написания проги, именно в это время программёр более всего шарит в проге.

Виды:

• Вводные – каждая прога должна включать: назначение, синтаксис вызова, список и назначение осн. переменных и массивов, указание по вводу выводу, список всех файлов, список использ подпрограмм, название методов, список литературы, объём памяти, специфические указания оператору, сведения об авторе

• Оглавление– если прога очень большая, то в её начале помещают оглавление виде комментариев(название, размещение и функции каждой подпрограммы)

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

Расположение комментариев – выделяются пустыми строками, заключ-ся в прямоугольники, располагайте комментарии так, чтобы это не делало её менее наглядной. Коментарии должны быть должны быть правильными и изменяться в процессе изменения проги. Неправ комментарии хуже чем их отсутств.

Пропуски строк используются для отделения параграфов, рекоменд пропуск строки после опер безусл передачи управл.

Пробелы облегчают чтение, рекоменд ставить пробелу между элементами списка, +,-,:=.

Имена переменных должны быть выбраны так чтобы наилучш образом определить те величины, к-рые они представляют, если огранич на длину имени отсутств, используют имена настолько длинные настолько нужно, но не длиннее. Запреты : избегайте схожих по виду описаний, имена должны отлич психологич, цифры пишутся в конце имени, когда имя содерж избыт инф. это тоже плохо, в качестве индиф исп-ть те названия к-рые прим-ся в той области для к-рой решается задача. Для различных типов данных имена должны начинаться с соотв символов (dNorm, nIter). Имена файлов должны содержать «file».

Стандартные сокращения позволяют программистам понимать тексты прог. Соглашения Джексона: каждое значимое слово должно сокращаться но не больше 3-х, в аббревиатуру всегда должна включаться 1-я буква, согласные важнее гласных, начало важнее конца, аббревиатура должна включать 6-15 букв. Алгоритм: из слова удаляются все гласные с правого конца, пока либо все гласные не будут удалены, кроме первой, либо слово не уменьшиться до требуемого размера, если слово больше то удаляются согласные.

Перенос рекомендуется делать после знака операции. Это позволяет избежать ошибки, когда 2-я строка оператора может быть выброшена.

Размещение операторов – одного оператора в строке достаточно.

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

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

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

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

9. Проектирование программ. Структурный подход.

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

Программу снабжают комментариями, делят на параграфы, она становится ясной и точной. Одна из систем – один пишет, 2-й пытается понять написанное. Если 1-й не в состоянии дописать то 2-ой доделает.

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

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

Если предлагают выбрать язык, то подходящий для задачи язык высокого уровня – наилучший выбор.

Универсальностью будем н-ть независимость программы от конкретного набора данных. Хорошая универсальная программа должна обрабатывать вырожденные случаи и печатать сообщение об ошибке. Используйте в качестве параметров переменные, а не константы. Должна быть независимость проги от конкретного набора данных. { For i:=1 to 25 do read(a[i]), лучше Const N = 25;… For i:=1 to N do read(a[i]) }

Процедура изменения констант на новые значения отнимает много времени, может вызвать появление ошибок. Переменные вместо констант: размер таблиц, массивов, устройств ввода- вывода. В простой проге переменные можно поместить в начале. Если сложная то полезно выделить подпрограмму, которая задавала бы начальные значения всех параметров. Параметры могут быть полезны в процессе отладки. Создавайте универсальные программы, при этом можно предугадать возможные изменения её спецификации.

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

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

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

Более скромные по целям работающие программы полезнее неоконченных грандиозных проектов.

Цели: высокий уровень надёжности, выполнение нек-рого объёма данных к определ дате, миним время разработки или стоимость, эффект., универсальность, модифицируемость. Если прога должна быть сделана быстро и потом не будет модифицироваться то не надо усложнять. Наиболее важные параметры время и память, но есть ещё и сложность. Чем сложнее программа, тем труднее ее контролировать, тестировать, отлаживать и эксплуатировать. Устанавливайте цели проекта заблаговременно и точно.

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

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

• Модульное программирование – процесс разбиения проги на модули и последующее их программирование. Каждая задача должна делиться на модули. Цели : необх добиться того, чтобы програмн модуль был правильным и не зависим от контекста, следует стремиться к тому чтобы из модулей можно было строить большие проги. Требования к модулям: короткие лучше длинных, независимость. Хороший модуль должен быть подобен математ функции.

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

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