1.
Программируем "по-крупному"
...Непременный атрибут процесса
создания программ. Первая "г",
последняя "й". Восемь букв.
- Геморрой...
- Гм... подходит!..
Из разговора двух программеров.
Тема, вынесенная в заголовок данной
статьи (в заголовок,а не эпиграф!),на пер─
вый взгляд, не очень ясна и понятна. "Что
значит по-крупному?! Мы по мелочам не раз─
мениваемся! У нас что ни проект,то шедевр!
Дискеты с исходниками скоро солить будем!"
Ну и далее в таком же духе. Именно о боль─
ших (в прямом смысле) проектах и шедеврах
кодерской мысли сегодня пойдет разговор.
Как не утонуть в большом исходнике, как
не потерять плоды многомесячного труда по
вине какой-то плохо читающейся дискеты,как
сделать свои исходники хотя бы немного бо─
лее понимаемыми другими людьми - обо всем
этом будет рассказано в этой статье. Мно─
гие вещи могут показаться очевидными и
элементарными. Но всего на свете знать не─
льзя, а опыт приходит со временем. Поэтому
искренне надеюсь, что каждый почерпнет для
себя хоть что-то новое и полезное. Итак,
начнем.
С чего начинается процесс обучения ас─
семблеру? Сначала из книжки после долгого
пыхтения набирается какой-нибудь здоровен─
ный исходник (размер его обратно пропорци─
онален лени и прямо пропорционален желанию
научиться программить).Потом делаются (за─
частую безуспешные) попытки разобраться,
как же все-таки оно работает. Разобравшись
с грехом пополам в одной процедуре,начина─
ющий программист далее идет одним из двух
путей. Первый: "Да ну его нафиг. Сложно
сильно. Не для меня". И второй: "Ёлки-пал─
ки! Да тут же делать нечего!Я не хуже могу
написать, а то и лучше!" Мысленно попроща─
емся с последователями первого пути и
опять-таки мысленно похвалим представите─
лей второго. И что дальше? А дальше наш
гипотетический программист начинает мучить
эту несчастную процедуру, постепенно её
наворачивая,оптимизируя,сокращая. Наконец,
это ему надоедает,и процедура находит свое
успокоение на одной из множества дискет, а
то и на бумаге.Постепенно таких вот проце─
дур накапливается довольно много и, нако─
нец,накапливается критическая масса, после
которой наступает моральная готовность на─
писать Настоящий Большой Проект. Появивше─
еся было желание написать все "с нуля" ку─
да-то быстро испаряется,и возникает другое
желание - взять свои старые процедуры, ко─
торые "не так уж и плохи". Замечательно,
программист берет, собирает процедуры по
куче исходников в один исходник, запускает
компиляцию, и... получает кучу сообщений
типа:
Label METKA is already used.
Ну да, никто ж не думал, что всем этим
процедурам придется когда-нибудь работать
вместе, поэтому не позаботились об уника─
льности меток.Начинаем делать "уникальную"
работу - исправлять метки так, чтобы они
отличались в разных процедурах (пока наш
программист вовсю старается и гнет пальцы
об клавиатуру, счастливые пользователи
Alasm делают финт ушами,пишут нечто вроде:
Procedure1:
LOCAL
metka: ...
...
ENDL
Procedure2:
LOCAL
metka: ...
@MyGlobalMetka:
...
ENDL
И спокойненько плюют в потолок).
Ура! Программа собрана в один исходник,
все нужные процедуры собраны, есть костяк
программы,все даже и работает. Тут начина─
ется самое интересное: программа изрядно
разбухает, перестает влезать в один файл
исходника, и ее опять приходится "пилять"
на части (разумеется, это касается только
тех ассемблеров, которые поддерживают та─
кую возможность). Тут можно также пойти
двумя путями - разделять на куски по прин─
ципу "сколько влезет и чтоб с запасом" и
разделение по функциональному признаку -
файловые операции, операции с устройствами
ввода,графические операции и т.д.Очевидно,
что последний вариант предпочтительней как
в плане написания, так и в плане сопровож─
дения кода.
В процессе разработки программы раз за
разом в текст вносятся изменения, часть из
которых довольно рискованная (было "хоро─
шо", пытаемся делать "ещё лучше", вопреки
правилу "лучшее - враг хорошего").
Хотелось бы иметь возможность вернуться
к старой версии текста, если что-то пойдет
не так. Так мы подошли к проблеме хранения
исходников и контроля версий. Для отдель─
ных текстов можно предусмотреть сохранение
резервных копий (обычно 1-2 бывает вполне
достаточно) с несколькими отличительными
символами в именах файлов, чтобы сразу оп─
ределить первоисточник.На более глобальном
уровне можно выполнять архивирование всех
исходных файлов проекта. Для хранения ар─
хивов отвести один-два диска на проект и
использовать даты в качестве имён файлов.
Также можно поместить в архив текстовый
файл с кратким описанием проекта,изменений
относительно прошлой версии и т.д.Для эму─
ляторщиков представляется дополнительное
удобство - можно не морочить голову, а ар─
хивировать целиком образы дискет,не рискуя
забыть поместить в архив тот или иной нуж─
ный файл.Также крайне рекомендую регулярно
распространять свои архивы по знакомым и
сайтам ( opensourcezx.narod.ru именно для
этих целей и создан) чтобы в случае чего
не остаться на бобах. Тот факт, что после
потери последней версии можем остаться со
старой, в которой не реализовано много ве─
щей,не должен являться проблемой.Как гово─
рит мой учитель (и я с ним полностью сог─
ласен), хорошая программа пишется дважды,а
то и трижды.
Если планируется распространять прог─
рамму с открытым кодом, или разработка ос─
тановилась, но планируется вернуться к ней
позже, необходимо обеспечить удобство про─
чтения кода, особенно другими людьми (хотя
лично я терпеть не могу разбираться в чу─
жих исходниках и программах, легче свое
написать). На эту тему можно предложить
несколько замечаний.
1) Каждый файл исходника предварять "ша-
пкой" с кратким описанием файла, возможно,
списком функций и историей изменений (осо─
бенно актуально при коллективной разработ─
ке), прочими данными (дата, автор).
2) Использовать по возможности единый
стиль оформления исходных текстов - с от─
делением операндов пробелами или табуляци─
ями (например, мои исходники, набранные на
реале, разделены табуляцией,в то время как
более поздние, созданные под эмулятором,
разделены пробелами, потому что до Break'а
сложно дотянуться %)).
3) Применять визуальные комментарии-раз─
делители, например:
;------- близкие по функциональности блоки
;======= менее близкие
;******* "шапки", описания и т.д.
;\\\ ну и так далее %)
4) Можно делать описания для функций -
что делает, какие входные параметры, какие
выходные, какие регистры и память портит,
прочие замечания.
К вопросу оформления меток. Так уж сло─
жилось,что на спектруме прижился Unix-овс─
кий стиль оформления меток - один регистр,
а слова разделены знаком подчеркивания
(людипомогитенеработаетпробелчтоделать?! -
настоящие_кодеры_пробелом_не_пользуются!).
Для тех ассемблеров, которые по умолчанию
используют нижний регистр букв,можно испо─
льзовать написание меток с использованием
больших букв. Тут тоже есть два стиля -
Pascal (каждое слово в словосочетании пи─
шется слитно и с большой буквы, т.н. "дву─
горбый верблюд": OpenFile ) и Java (все
слова, кроме первого, пишутся слитно и
с большой буквы, "одногорбый верблюд":
openFile ). Также весьма удобным выходом
иногда служит использование "венгерской
записи". Она применяется только для пере─
менных, в начало имени которых добавляется
небольшой префикс, определяющий тип пе─
ременной: b - byte, w - word, sz - string,
p - pointer etc. Взглянув один раз на наз─
вание переменной, можно без особого труда
определить (предсказать?) ее тип.
Если файл состоит из какого-то ограни─
ченного набора процедур, внутренние метки
в этих процедурах можно формировать как
сокращенное название процедуры + порядко─
вый номер, например:
PRINTLINE
...
PL0 ...
...
PL1 ...
RET
Таким образом, уменьшается вероятность
придумать своей буйной фантазией метку,
которая уже задействована.
Вот, пожалуй, и все, что мне хотелось
рассказать вам сегодня, чем хотелось поде─
литься. Если у кого есть свои методы "об─
легчения" нелёгкого процесса программиро─
вания,прошу сообщать в любой доступной фо─
рме.
Vitamin
2.
Дисциплина программирования.
Хочется и со своей стороны дать неско─
лько опробованных временем советов.
Убедите себя в том,что любое творчество
важнее потребления.Это станет ключом к по─
ниманию логики выше- и нижесказанного.Всё,
что вы создаёте, нужно,кто бы вам не твер─
дил обратное. Ответственность за сделанное
вторична,но и она существует. Надо её лишь
чувствовать - и по отношению к откровенной
халтуре, и к программе,которая грозит пор─
тить людей.
Всякую программу можно улучшить.Бойтесь
соблазна "последних версий".Не прекращайте
проект только из принципа,и уж тем более -
не стирайте исходники. Будет лучше ВАШЕ
исправление через месяц, чем исправление,
неаккуратно сделанное хакером спустя год.
Берегите исходники и всегда дублируйте
их. Так же относитесь к сопутствующим фай─
лам. Не доверяйте "жёстким дискам".Коробка
дискет служит дольше и отнюдь не имеет
обыкновения портиться целиком и без шансов
на восстановление. Ещё лучше копировать
исходники друзьям. Не бойтесь, что кто-то
выпустит вашу программу под чужим именем:)
Храните старые версии исходников - это
помогает исправлять ошибки в программе.
Оптимизацию следует проводить самостоя─
тельно,слепо не следуя каким-либо методам.
Большинство таких методов не универсально
и пасует в половине случаев перед другими
методами. (Я опишу несколько методов в
другой статье.)
Программу большого размера стоит опти─
мизировать по размеру. Иногда сокраще─
ние размера программы может сильно упрос─
тить её структуру, освободив какую-нибудь
область памяти.
Программу,скорость или время работы ко─
торой можно измерить в секундах или гер─
цах, имеет смысл ускорить. Как правило,это
процесс поэтапный и конца ему не видно,что
бы ни утверждали о десяти процентах приве─
рженцы языков высокого уровня (ЯВУ).
(Вразрез с вышесказанным:)
Программу, которую хорошо бы выпустить
в некий срок,стоит успеть выпустить в этот
срок. Часто для этого можно пожертвовать
оптимизацией и уж наверняка - парой пропу─
щенных телефильмов. Желательно оставить за
собой право доработки после.
Если вам не удаётся ничего, кроме отде─
льных процедур, и те плохо, и при этом вы
не можете довести до сборки ни одной заду─
манной крупной программы,не отчаивайтесь -
просто пишите, пишите, пишите до победного
конца! Программы на деревьях не растут, а
программисты с небес не падают - если не
лениться, то всё получится, и, конечно же,
с каждым разом легче!
Вы можете программировать эффективнее,
чем вы сейчас программируете. Вам кажется,
что это невозможно?
A. Coder
