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