Программирование снизу вверх наискосок.
"...Тогда достаточно закодировать:
G L о р
и вы можете быть уверены,что все
действия будут выполнены безоши-
бочно и эффективно."
Э.Йодан,президент
JоRDоN INс., N.Y.
"Может ли господь бог написать про-
грамму, которую он не сможет отла-
дить? "
Безошибочный кодировщик,
вZYск SYSтем Lав.МемвеR,мIсн.
В последние годы на капиталистическом западе как грибы после дождя
разрабатываются всяческие "теории" программирования, призванные, якобы,
облегчить написание, отладку и сопровождение больших программных
комплексов. Очевидно, что будучи продуктом буржуазной идеологии и выражая
интересы правящего класса, эти теории призваны отвлечь широкие массы
программистов от их истинных интересов. К сожалению, и у нас отдельные
товарищи попали под тлетворное влияние теорий "структурного",
"модульного", "нисходящего или восходящего" программирования, забывая, что
чем дольше программист отлаживает программу, тем безошибочнее и
эффективнее она когда-нибудь будет работать. Поэтому давно назрела
необходимость противопоставить этим лжетеориям нашу домашнюю, самодельную,
выстраданную и вымученную методику программирования. Опыт такой методики и
предлагается читателю. Мы назвали наш метод "GLорING рRоGRаммING" или
"снизу вверх наискосок" (свн). Основную идею метода свн лучше всего
передает древняя восточная мудрость: "Если что-нибудь можно сделать двумя
способами, не пожалейте усилий и придумайте третий".
I. С чего начать.
Многие западные программисты утверждают, что прежде чем начинать
писать программу, необходимо время на обдумывание алгоритма, а некоторые
даже призывают вникнуть в суть задачи, которую предстоит решать.
Категорически не следует интересоваться постановкой задачи до момента
получения обьектного модуля программы. Помните, что программирование - это
искусство, поэтому любые лишние знания только ограничивают вашу фантазию.
Начинайте писать текст программы задолго до того, как вам сформулируют
техническое задание, и вы получите прекрасную возможность сделать жизнь
вашего руководителя (и свою) гораздо разнообразнее и интереснее (например,
в момент получения тз вы можете возмутиться: "Представляете, сколько
теперь придется переделывать?!").
Никогда не составляйте заранее блок-схему программы. Во-первых, это
проще и быстрее сделать, когда программа уже написана, во-вторых,
неосторожно оставленная на столе блок-схема даст вашим врагам и
завистникам возможность понять, что вы собираетесь делать. Помните, что
никто кроме вас не должен разбираться в вашей программе. И если вы никак
не можете избавиться от дурной привычки рисовать блок-схемы, то зарубите
себе на носу:
Чем больше структура программы соответствует ее логике, тем меньше вы
стоите как программист.
II. Стиль.
Этому модному словечку многие западные адепты и апологеты придают
особый, чуть ли не мистический смысл. Безусловно, каждый программист или,
там, композитор имеет право писать в своей манере, однако, учитывая обьемы
програмных разработок, необходимо считаться с реальностью. Как и все
остальные,
программирование должно быть экономным!
Тратить до 50% перфокарт и обьема листинга (слово-то какое!) На
комментарии, пробелы, пустые операторы, звездочки и другие украшательства
- совершенно недопустимая расточительность. Пишите со 2-ой по 71-ую
позиции, всемерно избегая пробелов. Если комментария никак не избежать,
стремитесь писать их как можно конкретнее. Например:
Dо J=1 то N; /* сYсL ро N*/ IF J>0 тнеN Gото м; /*реRехоD
то м*/ еLSе Gото L; /*реRехоD к L*/ х=х+1; /* рRIваWIтх 1 к
х/* еND; м: Х=х-1; /* так надо федя! */ IF а тнеN Gото L;
L: /* ВозVеSтY х Sтер. Два*/ х=х**2; ... И т. Д.
Всем переменным давайте имена ваших знакомых, любимых блюд, эстрадных
ансамблей, сигарет, напитков и т. Д. Легко видеть, что фрагменты типа:
IF катJа >= 18 тнеN Dо; саLL GаSтRоNом; саLL тахI; Gото
хата; еND; еLSе Gото VеRа;
/* рL/1 */
GLорING сSест
...
МаRINа еQU DURа
...
L ан,маRUSJа
Sт Uн,аNJUта
вхLе LетS,IRINа,DRINк(аGDам)
/* аSSемвLеR */
поражают изяществом, остроумием и тонким вкусом.
При внимательном рассмотрении легко обнаруживается, что буржуазные
авторы книг рассуждая о предмете, который они называют "структурным
программированием", тонут в собственных противоречиях. Например, [д.
Майерс], стр. 63: "Скромные по целям работающие программы лучше
неотлаженных грандиозных проектов", а на стр. 58: "Если незначительное
добавление сделает вашу программу пригодной для другого случая, никогда не
пренебрегайте этим". Мы готовы согласиться с последним утверждением,
поскольку умелое его применение позволит вам затянуть разработку программы
на любой мыслимый срок.
Более того, тот же автор через несколько страниц, вспоминает
пресловутый принцип к I S S (кеер Iт SIмрLе, SтUрID - будь проще, дурачок!
). Представляете, в один прекрасный день руководитель заявляет вам:
"Что-то у вас очень уж просто все получается! "
Эти структурно-экстремистские тенденции, в конце концов, приводят к
полному вырождению программирования как творческой деятельности.
Предельная степень деградации порождает методы типа ашкрофта-манны [э.
Йодан], сводящие деятельность программиста к работе ч. Чаплина на
конвейере в к/ф "новые времена".
III. Gо то
проблема безусловных переходов, к счастью, еще не нашла
окончательного решения. Среди программирующей западной молодежи
распространено заблуждение, что использование оператора Gото крайне
нежелательно. Практика ведущих программистов нашей лаборатории показывает,
что использование оператора безусловного перехода в сочетании с массивами
меток повышает эффективность программ в среднем на 4.2% При увеличении
времени отладки на 350-400%.
Если нужно перейти из данной точки
программы, следует перейти как можно
дальше. Если перейти некуда, следует
пересмотреть программу
очень удачны бывают переходы в тело цикла Dо, особенно из других
модулей. Хотя трансляторы, как правило, это запрещают, их легко можно
обвести вокруг пальца, пользуясь переменными типа метки. Передача
управления в вызываемую процедуру в обход заголовка принесет вам долгие
часы счастливых раздумий над кодом завершения 0с5.
Все вставки в программу следует делать так: После последнего
оператора ставьте новую метку, напишите текст вставки, увеличьте
размерность массива меток на 2, передайте управление на эту метку из
нужной точки (или откуда-нибудь еще), пометьте оператор, следующий за
Gото, новой меткой, смело измените значение переменной метки и вернитесь.
Вообще говоря, на каком языке вы бы ни писали программы, лучше, если
каждый оператор будет иметь свою метку (как это предусмотрено в фортране).
Степень вашей квалификации, как программиста в стиле свн, определяется
соотношением:
N
SIGма ( V(I)+W(I) )
I=1
к = ------------------- , где ( 1 )
N
N - число операторов,
V(I) - число передач управления на I-тый оператор,
W(I) - число возможных переходов от I-го оператора.
При к < 0.5 Вы, как программист, никуда не годитесь. Приемлимый
коэффициент 3 - 4, а некоторые суперпрограммисты имеют к не ниже 12.
IV. Модульность.
Н и к а к о й м о д у л ь н о с т и! Вообще...
V. Эффективность.
Споры по поводу того, что считать эффективной программой, не утихают
с тех пор, когда в спортзале заработала эвм м-20. В наши дни дело дошло до
появления казуистических утверждений вроде: "Удобочитаемость программы
существеннее ее эффективности" [д. Майерс].
Мы считаем, что эффективность программы является совершенно
обьективной и количественно оцениваемой величиной. Не надо жалеть ни
времени, ни усилий в борьбе за эффективность - когда ваша программа в
конце концов заработает, все ваши затраты окупятся экономией 15 мксек и о.
073 Кб. Чтобы программист мог заранее оценить эффективность своего
продукта, предлагается простая формула:
Э = т/т1 + I*т/т2, где (2)
т1 - время, требуемое срU для выполнения вашей программы, (если
программа еще не выходит на Gо, т1 = т);
т - время, необходимое для вывода на ацпу заранее заготовленного
текста, идентичного тому, который будет печатать ваша программа, когда
выйдет на Gо;
т2 - время, которое ваша программа будет выполняться, когда вы ее
полностью отладите.
I = SQRт (-1)
эффективность программы, как видно, величина комплексная, что
отражает системный подход к программированию, характерный для метода свн.
Таким образом, как следует из выражения (2), сроки написания и
отладки программы никоим образом не влияют на ее эффективность. Многие
программисты, по-видимому, интуитивно пришли к пониманию этого факта и
годами улучшают свою программу, делая ее все более эффективной за счет
уменьшения параметра т2.
Кстати, один из апологетов "структурного программирования" [д.
Майерс], позволил себе следующее: "Никто, будучи в здравом уме и твердой
памяти, не станет программировать на ассемблере." И это по поводу любимого
языка сторонников свн! Напротив! Изучение ассемблера - это прекрасный путь
к вершинам познания ос ес эвм. Следуя этим путем, вы получите массу
полезных знаний, которые помогут вам решить ряд важнейших проблем:
1). Как, получив талончик на одну минутку в пакете, захватить в
безраздельное пользование срU по крайней мере на 1.5 Часа, устранить
задачи всех других пользователей (например, с кодом S422), застопорить
очередь заданий, лишить оператора возможности снять ваше задание,
беспрепятственно получить результаты (не взирая на установленный лимит
расхода бумаги), и при этом - все претензии операторской службы овт
направить в сторону какой-нибудь кафедры факультета "ф"?
2). Как испортить (не стирая) все чужие нд на вашем пакете 5050/5061,
не оставляя следов в рRINтLоG?
3). Как стереть ядро? (Или IрL?)
Вообще, существует богатейший спектр способов повышения эффективности
программ. Авторы хорошо и давно знакомы с одним программистом, который не
так давно выиграл на пари ящик пива, повысив, за 40 минут поверхностного
анализа, минимум в два раза быстродействие трех программ на фортране,
взятых наугад из мусорной корзины на одной из кафедр ф-та "т". Поскольку
этот факт абсолютно не известен руководству, программистам в стиле свн
предстоят долгие годы безоблачного существования и счастливого
программирования.
VI. Снова модульность.
По прежнему, никакой модульности!
(Поскольку модульность нельзя понимать иначе, как наличие известной
встроенной функции. Все остальное - от лукавого.)
Считайте себя хуже других, если вы не в состоянии написать программу
(если хотите, назовите ее модулем) длиной более 1000 операторов. Если по
ряду обьективных причин (они есть всегда) вам все-таки приходится
сталкиваться с проблемой стыковки, то помните об одном-единственном
правиле метода свн:
Никаких соглашений о связях!
В особенности, если приходится иметь дело с программистами
противоположного пола.
Согласно статье 94 процессуального
кодекса, при разборе дел об
установлении отцовства протокол
соглашения о связях учитывается
наравне с доказательствами совместного
ведения хозяйства.
Кроме того, как уже подчеркивалось, любые ограничения вашей фантазии,
как программиста, не принесут ничего, кроме снижения сроков разработки
проекта и, тем самым, уменьшения эффективности конечного продукта.
Порадуйте своего руководителя, повесив над рабочим столом плакат:
"Программирование - слишком сложная интеллектуальная деятельность, чтобы
можно было надеяться навязать ей узы административной системы, которая
душит всякую инициативу." [ван тассел]. Если реакция руководства окажется
более сдержанной, чем вы ожидали, перекрасьте дверь вашей лаборатории
зеленой краской самого ядовитого цвета и исчезните на три дня,
предварительно отключив домашний телефон [б. Мейер, бодуен].
VII. Отладка.
Первая заповедь программиста, успешно преодолевшего барьер
синтаксического контроля - не торопиться. Помните, что плохо отлаженная
программа всегда менее эффективна, чем совсем не отлаженная. Не выводите
на печать более одной переменной за один прогон. Полученные листинги
(распечатки) немедленно уничтожайте (во избежание!.. См. V). С другой
стороны, полезно хранить, в единственном экземпляре, протокол компилятора
с наихудшим (это не сложно) качеством печати с тем, чтобы при
незапланированном появлении руководителя можно было бы сказать: "Вот
видите, в каких условиях приходится работать!" Разумеется, диагностические
сообщения следует отрезать, а лучше - неаккуратно оборвать. (Для тех, кто
программирует на фортране или ассемблере, рекомендуем приобрести некоторые
навыки работы с ножницами и клеем).
Если вы храните исходный текст на нмд, никогда не проверяйте карт
IевUрDте, и чтобы не лишать себя приятных неожиданностей! Более того,
проверять пробивку - дурной тон и признак гнусного неуважения к милым и
очаровательным девушкам, тратящим лучшие годы юности на пробивание дырок в
ваших перфокартах.
Когда заканчивается отладка, начинается эксплуатация! Ни один
уважающий себя программист не допустит, чтобы его любимое чадо, плод его
многолетних трудов и страданий эксплуатировали какие-то посторонние люди.
Несколько слов о тестировании. Никто не знает, в чем именно
заключается тестирование, что является конечной целью и какие результаты
следует получить. В методе свн принято считать тестирование законченным,
если выполнение завершается с кодом возврата 0000, даже если исходные
данные различаются хотя бы одним числом (или всеми - если вы максималист).
После окончания этапа тестирования уничтожте исходный текст. Только в
этом случае вы можете быть абсолютно уверены, что вашей программе никто не
причинит никакого вреда и она останется такой же эффективной, какой была
всегда.