Правило #8, про ініціалізацію масивів

Масиви із заздалегідь визначеними значеннями (якщо їх не потрібно за завданням вводити з клавіатури або з файлу) ініціалізувати НЕ операторами присвоювання, а з використанням ініціалізаторів і типізованих констант в мовами Сі і Паскаль, відповідно. Невірно: double matrix[3][3]; .... matrix[0][0] = 1.5; matrix[0][1] = 2.5; ...... Matrix : array[1..3, 1..3] of extended; ...... Matrix[1,1] := 1.5; Matrix[1,2] := 2.5; Правильно: double matrix[3][3] = { {1.5, 2.5, ... }, {...}, {...}, }; const Matrix: array[1..3, 1..3] of extended = ( (1.5, 2.5, ...), (...), (...) );

Правило #9, про функції/процедури

1. Функції ПОВИННІ БУТИ Програма без підпрограм - майже свідомо погана програма, за винятком програми, яка виводить повідомлення "Hello, world!" (не завжди),. 2. У функцій повинні бути параметри Функція, що використовує глобальні змінні - майже напевно погана, бо ситуації, коли всередині функції необхідно використовувати глобальну змінну, вкрай рідкісні. Підпрограма, що реалізовує, наприклад, метод Гаусса для рішення систем лінійних рівнянь і не має параметрів - це ЖАХЛИВО. Це як мобільний телефон, з якого можна дзвонити тільки на один назавжди заданий номер і на який можна телефонувати теж тільки з одного номера (причому з таксофона). 3. Функції повинні бути короткими 2 екрану (50 рядків) максимум. Це стосується і головної функції програми, main() в мові C або головних begin end. мовою Pascal. Єдине виправдання довгою функції - це наявність в ній оператора множинного вибору з великим числом альтернатив. 4. Функції повинні виконувати РІВНО ОДНУ ДІЮ. Наприклад, підпрограма, яка виконує рішення системи лінійних рівнянь, НЕ ПОВИННА займатися читанням вихідних даних, вона повинна отримати їх у вигляді аргументів. Вона також не має виводити результати куди б то не було. Це повинна робити інша підпрограма.

Правило #10, про помилки та ще дещо про що

Якщо та чи інша функція потенційно може закінчитися невдало, це ОБОВ'ЯЗКОВО слід перевіряти. Це захистить Вас і викладача(!) від довгих хвилин тупого споглядання екрану в спробі зрозуміти, чому Ваш витвір падає на рівному місці або поводиться у вищій ступеня загадково. Невірно: char * buf; buf = (char*)malloc(/*багато-багато байт*/); buf[0] = some_value; Правильно: char * buf; buf = (char*)malloc(/*багато-багато байт*/); if ( !buf ) { perror("немає пам'яті"); exit(1); }; buf[0] = some_value; Якщо виникла помилка така, що програма/підпрограма далі виконуватися не може, умова перевірки на помилку КРАЩЕ писати так, щоб воно було ДІЙСНИМ, якщо СТАЛАСЯ помилка, а не навпаки та код будувати так, щоб уникати обороту else в операторі if. Пам'ятайте, що з програми/підпрограми можна вийти в будь-якому місці, не обов'язково в кінці її тексту. Невірно: char * buf; buf = (char*)malloc(/*багато-багато байт*/); if ( buf ) { /* тут сторінка коду */ } else { perror("немає пам'яті"); }; Цей else може бути далеко від if, що зменшує ясність програми. Правильно: char * buf; buf = (char*)malloc(/*багато-багато байт*/); if ( !buf ) { perror("немає пам'яті"); /* виходимо */ exit(BAD_EXIT_CODE) /* або return BAD_RET_VAL; */ }; /* у цьому місці все добре, продовжуємо */