4. Плюси і мінуси методик програмування

Після того, як ми розібралися по суті обох методик, давайте розглянемо, які зручності ми отримуємо від їх використання, і з якими проблемами стикаємося.

Програмування від низу до верху	Програмування зверху вниз
Переваги
Можна об'єднати одночасно декілька підпрограм або модулів, оскільки часто одна підпрограма вищого рівня в проекті замінює відразу декілька драйверів.	Серйозні помилки з великою вірогідністю відшукуються вже на ранніх стадіях проекту.
Підпрограми, що розробляються на ранній стадії роботи над проектом, часто виявляються надзвичайно корисними і в інших випадках. Зазвичай такі низькорівневі підпрограми об'єднують у власні бібліотеки.	На любом этапе мы можем работать всего с одной подпрограммой, а это позволяет легче отлаживать и изменять код.
Залежність від машинних ресурсів в цілому виходить менше, оскільки тільки на пізніх етапах проекту ми працюємо з великим об'ємом коду.	Простіше дотримуватися єдиних правил при створенні різних версій програми. При цьому створювати корисні приватні підверсії також виявляється зручно.
	Тестування виявляється більш систематичним.
Недоліки
Вже реалізовані, відладжені і протестовані модулі іноді доводиться відкидати, якщо в зухвалих частинах програми виявилися неусувні помилки, і необхідно переробляти цілий блок.	Якщо виявляється, що модуль низького рівня неможливо реалізувати, як замислювалося, іноді доводиться переробляти весь проект.
	При відладці поглинається більше машинних ресурсів

Жоден практикуючий програміст, звичайно, жорстко не дотримуватиметься однієї з показаних методик. У справжній роботі ми завжди використовуємо і ті, і інші прийоми.

5. Інші проблеми структурного програмування

1. Текст програми повинен бути легкий для читання і зрозумілий людині. Існує декілька хитрощів, які допомагають зробити код читабельним:

• Писати треба просто. Програмісти, що починають, частенько перетяжеляют код, використовуючи "красиві" хитромудрі конструкції. Проте, цим вони отримують відразу два головні болі: по-перше, такий код складніше читати, а по-друге, в мудровані ділянки легко внести помилку. Звичайно, в будь-якому питанні потрібно дотримуватися золотої середини. Алгоритм бульбашкового сортування, скажімо, запам'ятати найлегше, але на практиці краще використовувати ефективніші методи.

• Використовувати синтаксичні угоди. Перш за все, до них відноситься система синтаксичних відступів. Кожен наступний вкладений блок відсовується щодо попереднього на декілька позицій (зазвичай 2-3). У текстовому редакторові середовища цей відступ зручно вказати як ширину поля табуляції. Насправді, порівняєте приведені уривки:

• { варіант з синтаксичними відступами}

• for i:=1 to n do

• for j:=1 to n do begin

• C[i,j]:=0;

• for k:=1 to m do

• C[i,j]:= C[i,j]+A[i,k]*B[к,j];

• end;

• { варіант "суцільної"}

• for i:=1 to n do

• for j:=1 to n do begin

• C[i,j]:=0;

• for k:=1 to m do

• C[i,j]:= C[i,j]+A[i,k]*B[к,j];

• end;

Ще більш не мають рацію ті, хто прагне "упакувати" максимум інформації в один рядок. Інша угода відноситься до імен змінних і називається "Угорською нотацією". До імені змінної додається префікс в декілька символів, тип, що позначає її. Наприклад, i для типу integer або s для string:

var

iWidth, iElement: integer;

sName, sFamily: string;

Ви поліпшите читабельність, якщо слідуватимете взаємному порядку операторів, описаному в початковій версії мови. Скажімо, вважається, що в Паскалі блок опису констант const повинен стояти перед блоком опису типів type. Середовище програмування, швидше за все не порахує помилкою, якщо ви поміняєте ці розділи місцями, але з міркувань читабельності краще за це не робити.

• Створювати ідентифікатори, що "говорять". Якщо ви використовуєте тільки однобуквені змінні "a", "x", "n", як в простих версіях Бейсіка, або ідентифікатори-абревіатури "nklm", "prs", як писали на старому Fortranе, чекайте неприємностей. Вам доведеться принаймні тягнути через весь проект довгі таблиці, що пояснюють призначення параметрів. Name завжди краще х, а OldValue - зрозуміліше а.

• Не лінуватися вставляти коментарі. Особливо складні алгоритми, оригінальні прийоми потрібно коментувати якомога докладніше, інакше, повернувшись через пару місяців до свого старого тексту, ви будете декілька годин наново проходити той же шлях. Зручно давати комментар-специфікацію до підпрограми відразу після або відразу до її заголовка.

• (******************************************************

• Функція лінійного пошуку m-го входження елементу в

• одновимірний масив. Повертає індекс m-го входження або

• -1, якщо такого елементу в масиві немає

• V - заданий вектор;

• num - реальна розмірність вектора;

• key - значення шуканого елементу;

• m - шукане входження

• count - порядковий номер поточного входження елементу

• im - індекс поточного входження елементу

• i - параметр циклу

• ******************************************************)

• function LinSearchM (V: Vector; num: integer; key: integer;

• m: integer) : integer;

• ...

• end;

• Нарешті, по можливості робити підпрограми невеликими, оптимально - не більш за одну друкарську сторінку.

Необхідно знижувати трудомісткість тестування і відладки програми (Вартість розробки - на 80% складається з вартості тестування і відладки. Тому, на жаль, саме на них і починають економити багато нинішніх розробників). Тут існує тільки один шлях: акуратніше складати код і ретельніше планувати тестування. У серйозних компаніях формують окремий відділ бета-тестирования, який займається виловом помилок - як інтерфейсних, так і внутрішніх.

Проблема верифікації - автоматичного доказу правильності роботи програми. Якщо програма відпрацювала правильно на десяти тестах, це, в принципі, не означає, що на одинадцятому вона не "впаде". Але ж не можна перевірити всі можливі комбінації параметрів, тому доводиться десь зупинитися. З теоретичної точки зору питання про верифікацію надзвичайно складне. На практиці зазвичай обмежуються вибраним для даного завдання набором тестів.

Спрощення модифікації програми. Будь-яка корисна програма зараз вимагає постійного оновлення, розширення функцій, випуску нових версій: на цьому і живуть серйозні софтверні корпорації. Краще всього, якщо створюючи першу версію, ви вже думатимете про наступну. Легкості змін служать і окремі прийоми програмування: використання об'єктів (а зараз компонентів), модульна структура, використання бібліотек, що динамічно підключаються, заготовок під майбутні функції і т.д.