одиться переробляти весь проект.
При налагодженні поглинається більше машинних ресурсів
Жоден практикуючий програміст, звичайно, не буде жорстко дотримуватися однією з показаних методик. У цій роботі ми завжди використовуємо і ті, і інші прийоми.
Інші проблеми структурного програмування
Текст програми повинен бути удобочитаем і зрозумілий людині. Існує кілька хитрощів, які допомагають зробити код читабельним:
o Писати треба просто. Початківці програмісти частенько перетяжеляют код, використовуючи "Красиві" хитромудрі конструкції. Однак, цим вони отримують одразу дві головні болі: по-перше, такий код складніше читати, а по-друге, в мудровані ділянки легко внести помилку. Звичайно, в будь-якому питанні потрібно дотримуватися золотої середини. Алгоритм бульбашкового сортування, скажімо, запам'ятати легше всього, але на практиці краще використовувати більш ефективні методи.
o Використовувати синтаксичні угоди. Насамперед, до них відноситься система синтаксичних відступів. Кожен наступний вкладений блок відсувається щодо попереднього на кілька позицій (зазвичай 2-3). У текстовому редакторі середовища цей відступ зручно вказати як ширину поля табуляції. p> o Ще більш неправі ті, хто прагне "упакувати" максимум інформації в один рядок. Інше Угода відноситься до імен змінних і називається "угорської нотацією ". p> o Ви поліпшите читабельність, якщо будете слідувати взаємною порядку операторів, описаного в вихідної версії мови. Скажімо, вважається, що в Паскалі блок опису констант const повинен стояти перед блоком опису типів type. Середовище програмування, швидше за все не порахує помилкою, якщо ви поміняєте ці розділи місцями, але з міркувань читабельності краще цього не робити.
o Створювати "Говорять" ідентифікатори. Якщо ви використовуєте тільки однобуквені змінні "a", "x", "n", як в найпростіших версіях Бейсика, або ідентифікатори-абревіатури "nklm", "Prs", як писали на старому Fortranе, чекайте неприємностей. Вам доведеться принаймні тягнути через весь проект довгі таблиці, що пояснюють призначення параметрів. Name завжди краще х, а OldValue - зрозуміліше a. p> o Не лінуватися вставляти коментарі. Особливо складні алгоритми, оригінальні прийоми потрібно коментувати якомога детальніше, інакше, повернувшись через пару місяців до свого старого тексту, ви будете кілька годин заново проходити той же шлях. Зручно давати коментар-специфікацію до підпрограми відразу після або відразу до її заголовка. p> o Нарешті, по можливості робити підпрограми невеликими, оптимально - не більше однієї друкованої сторінки.
Необхідно знижувати трудомісткість тестування і налагодження програми (Вартість розробки - на 80% складається з вартості тестування і налагодження. Тому, на жаль, саме на них і починають економити багато нинішніх розробники). Тут існує тільки один шлях: акуратніше складати код і ретельніше планувати тестування. У серйозних компаніях формують окремий відділ бета-тестування, який займається виловлювання помилок - як інтерфейсних, так і внутрішніх.
Проблема верифікації - автоматичного докази правильності роботи програми. Якщо програма відпрацювала правильно на десяти тестах, це, в принципі, не означає, що на одинадцятому вона не В«впаде". Але ж не можна перевірити всі можливі комбінації параметрів, тому доводиться десь зупинитися. З теоретичної точки зору питання про верифікації надзвичайно складний. На практиці зазвичай обмежуються обраним для даної задачі набором тестів.
Спрощення модифікації програми. Будь-яка корисна програма зараз вимагає постійного оновлення, розширення функцій, випуску нових версій: на цьому і живуть серйозні софтверні корпорації. Краще всього, якщо створюючи першу версію, ви вже будете думати про наступну. Легкості змін служать і окремі прийоми програмування: використання об'єктів (а зараз компонентів), модульні структура, використання динамічно підключаються бібліотек, заготовок під майбутні функції і т.д.
Ефективність програми. Оптимально програма займає мінімум пам'яті і виконується за мінімум часу. Останнім часом частенько ефективність програм підміняється "Необхідними системними вимогами" - користувача змушують постійно нарощувати потужність обладнання. Але якщо у конкурента вимоги до системі виявляться нижче, а процеси стануть виконуватися швидше, користувач неодмінно відвернеться від вашої програми.
