Правило #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, про функции/процедуры

9.1) Функции ДОЛЖНЫ БЫТЬ. Программа без подпрограмм - почти заведомо плохая программа, за исключением программы, выводящей сообщение " Hello, world! " (и то не всегда), см. пример в конце.
9.2) У функций должны быть параметры. Функция, использующая глобальные переменные - почти наверняка плохая, ибо ситуации, когда внутри функции необходимо использовать глобальную переменную, крайне редки. Подпрограмма, реализующая, например, метод Гаусса для решения систем линейных уравнений и не имеющая параметров - это УЖАСНО. Это как сотовый телефон, с которого можно звонить только на один навсегда заданный номер и на который можно звонить тоже только с одного номера (причем с таксофона).
9.3) Функции должны быть короткими, 2 экрана (50 строк) максимум. Это касается и главной функции программы, main() в языке C или главных begin end. в языке Pascal. Единственное оправдание длинной функции - это наличие в ней оператора множественного выбора с большим числом альтернатив.
9.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.