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

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

2. Давайте переменным осмысленные имена. Переменная с именем Length, или, в крайнем случае, Dlina, сама напомнит о своем назначении, в отличие от L. С другой стороны, не возбраняется использовать стандартные сокращения -- например, S для площади, P для периметра, a, b и c -- для сторон треугольника. Любые индексы естественно выглядят с именами i, j, k и т. д. Но если индекс обозначает номер месяца в году, куда естественней назвать его month, чем i. Хотя Паскаль и не различает регистр букв в именах переменных и служебных словах -- соблюдайте его везде. Большинство профессиональных языков регистр символов различают.

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

4. Создавая любую переменную, обратите внимание на следующие моменты:

· какой тип значений может принимать переменная, нельзя ли заменить ее перечислением, множеством или иным "сокращенным" типом данных?

· есть ли ограничения на допустимые значения, если да, где и как они будут учтены? · что произойдет при переполнении значения или попытке дать переменной недопустимое значение?

5. Закрывайте блоки сразу. Такой блок, как

if условие then begin end else begin end;

или

while условие do begin end;

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

6. Не оставляйте неработающее приложение "на завтра". Блочно-модульная структура программы позволяет всегда избежать этого. Подпрограмма может быть пустой "заглушкой", вы можете использовать ничего не делающие условия, пустые блоки, комментарии, но текущий код должен компилироваться, если завтра вы не хотите половину рабочего дня затратить на восстановление в памяти недоделанного сегодня.

7. Доводите программу до отсутствия предупреждений компилятора, а не только ошибок. Неизвестно, как скажутся на самом деле эти "невинные" напоминания. В языке Си конструкция вида if a:=0 допустима и вызовет лишь предупреждение "Possibly incorrect assignment" -- хотя в результате переменная a всегда будет получать значение 0 и ветвь алгоритма, привязанная к этому условию, будет всегда выполняться.

8. Выбирайте более короткие типы данных там, где это уместно: часто byte может заменить word или integer, а string[20] -- просто string.

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

10. Выбирайте менее трудоемкие операции. Так, n div k лучше, чем Trunc(n/k), а Inc(i); лучше, чем i:=i+1;. Во всех случаях порядковые операторы и операнды работают быстрее, чем вещественные. Поэтому обходитесь порядковыми данными везде, где это возможно. Особенно избегайте без необходимости деления на вещественные числа.

11. Не забывайте о погрешностях при работе с вещественными числами. Хрестоматийное while x<=2.5 do ... -- плохо, если x -- вещественный. С другой стороны, while abs(x-2.5)
12. Используйте стандартные функции языка, на котором пишете. Мнимая экономия ресурсов, достигнутая написанием собственных подпрограмм нижнего уровня, обернется трудноуловимыми ошибками в больших проектах. После пяти-десяти лет практики это становится ясно каждому программисту, хотя эксперименты с собственными интерфейсами и машинно-ориентированными программами бывают интересны и даже полезны на этапе обучения.

13. Следите за условиями. Если вы проверяете одно и то же условие неоднократно -- скорей всего, у вашей программы не в порядке с логикой. Пример из п. 7.7 показывает это наглядно.

14. Не забывайте о взаимоисключающих условиях. Составной условный оператор if ... else if или же case в таких случаях намного лучше набора коротких условных операторов.

15. Зачастую при написании длинных фрагментов кода удобнее обрабатывать ошибки в виде

if ошибка then завершение; обработка;

чем по схеме

if верно then обработка else завершение;

Вообще, избегайте else, находящихся строк через 100 после своего if -- это затрудняет восприятие даже хорошо структурированной программы.

16. Избегайте в циклах вычислений, не зависящих от их параметров! Выражение вроде sin(Pi/n), помещенное в цикл, где n не меняется, выглядит нелепо. Ведь каждое вычисление синуса (как и других стандартных функций) -- это трудоемкое разложение в ряд Фурье, выполняемое машиной.

17. Используйте математику там, где это уместно для сокращения трудоемкости кода и числа сравнений. Проверить, что переменные x и y имеют один знак, можно так:

if (x>0) and (y>0) or (x<0) and (y<0) then ...,

а можно и в виде if (x*y>0) then ....

18. Прекращайте циклы, когда результат уже достигнут. Приоритет средств при этом следующий:

· использование циклов repeat-until или while-do вместо for; · операторы break или exit; · в последнюю очередь -- goto, и только в случаях, описанных в п. 16.2.

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

20. Именуйте размерные константы массивов. Никому не нужны несколько циклов с верхними границами-"близнецами". А что, если размерность обрабатываемых данных придется изменить?

21. Передавайте значения подпрограммам преимущественно по адресу, а не по значению. Для матричных и векторных данных старайтесь делать это всегда. Применение векторных данных имеет приоритет перед матричными.

22. Не делайте подпрограммы зависимыми от глобальных данных. Несоблюдение этого правила существенно уменьшит вероятность повторного использования кода вами или другим разработчиком.

23. Не пишите подпрограмм, возвращающих более одного объекта -- скаляра, вектора или матрицы. В крайнем случае, можно отдельным параметром передавать или возвращать размерность векторных данных. Избегайте подпрограмм, которые ничего не возвращают. Разработка сложных подпрограмм облегчается, если их "точка выхода" и возвращаемое значение указаны единственным и последним оператором. Для перехода из тела подпрограммы в точку возврата в этом случае не грешно использовать даже goto:

function Test (a,b:integer):integer; label end_of_Test; var error:integer; begin error:=0; if (a<0) or (b<0) then begin error:=1; goto end_of_Test; end; . . . end_of_Test: Test:=error; end;

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

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

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

27. Если написанная вами программа не работает или работает "криво", ошибка лежит на вашей совести, а компьютер с компилятором ни в чем не виноваты. "Отладка", при которой программист хаотически меняет то одно, то другое место в коде и на которую уходит до 90% времени написания, на самом деле -- свидетельство не слишком качественной работы. Хорошо написанной программе нужна не столько отладка, сколько тестирование на различных допустимых, недопустимых и "пограничных" наборах данных. Кстати, обдумывание и написание тестов до тестируемого кода способствует и улучшению, и большей устойчивости конечного продукта.

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

---