8 (800) 333-3041Звонок бесплатный для
всех регионов России
Проектирование информационных систем Оглавление Отладка

Программирование

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

стремитесь к простоте
Не стоит писать на птичьем языке типа *p[i++] = ++n; или f1() && f2(); или for(i=0,p=5,&s=*p;exp1()&&exp2&&exp3()||exp4();i++,p++); Многие не помнят, в каком порядке происходят вычисления инкремента и не догадываются, что вы хотели вызвать функцию f2, если f1 вернула не ноль. Не заставляйте программиста, читающего вашу программу думать. Разбивайте сложные конструкции на несколько строк, расставляйте скобки.

имена переменных и функций должны быть осмысленными
;-) Везде это пишут и, все равно, как только не называют.

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

делайте одинаковое одинаковым
Если вы ставите фигурную скобку на новой строке или пробел после if, то будьте последовательны в своих действиях.

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

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

Далее идут рекомендации общего характера применительно к разработке CGI-программ. Повторное использование уже написанного ранее кода у вас будет значительно выше, чем в других проектах. Во многом это определяется вышерассмотренным правилом: "на каждую HTML-форму свой CGI-скрипт". Общие функции для нескольких CGI-программ выносите в отдельную библиотеку инструментов, именно так, у нас появилась библиотека ITCGI. CGI-программа должна быть максимально независима от дизайна и HTML-кода. Например, нижние и верхние колонтитулы мы считываем из файлов /include/head.inc и /include/footer.inc. Если CGI-программа должна выдавать данные, оформленные в определенном дизайне, то HTML-код лучше вынести в отдельный файл, а места, куда надо вставить данные, пометить, как ##имя_переменной##. В CGI-программе надо будет считать этот файл и выполнить соответствующую замену. В таком подходе есть недостаток, т.к. это несколько замедляет работу. При каждом вызове CGI-программы она должна считывать внешний файл и делать в нем замену. Но в таком подходе есть и свои плюсы, т.к. верстальщик, без непосредственного взаимодействия с программистом, может настраивать вывод CGI-скрипта. Еще очень важным моментом при разработке CGI-программ является хранение параметров в файле на сервере. Имеет смысл хранить параметры в файле с расширением .cfg, только в Apache обязательно запретите чтение этих файлов внешними пользователями. Это делается следующими строчками в файле httpd.conf:

 <Files ~ "*.cfg">
 Order allow,deny
 Deny from all
</Files>
В библиотеке ITCGI есть ряд функций для работы с параметрами на стороне сервера.

Eng
Наверх