Как не запутаться в коде?

← →
Lex (2003-08-28 13:49) [0]

Я хочу cпросить совета у уже опытных разработчиков больших программ. Я сейчас занимаюсь разработкой одной, пока еще по-большому счету никому не известной, но очень интересной карточной игры. Так вот, объем исходного кода уже исчисляется несколькими тысячами строк, десятками юнитов, потоков, dll-ок. Одна процедура вызывает другую, другая следующая, следующая первую, первая еще к тому же четвертую, вдруг запускается поток, и все это использует множество глобальных переменных, типов, которые описаные неизвестно где, непонятно зачем (сразу не вспомнишь) и в голове вмиг возникает большая каша, на которую, чтобы переварить и заново восстановить весь алгаритм, опять же нужно время. В итоге, в разработке приложения возникают совсем ненужные паузы. Посоветуйте мне, пожалуйста, как уменьшить колличество и продолжительность этих пауз? Расскажите об общих принципах, которых придерживаются программисты для облегчения задачи (наподобие: если переменная типа integer, то она должна начинаться на i) и которые я, возможно, просто еще не знаю...
P.S. Кроме "используй комментарии" еще что-нибудь можете посоветовать :)? Просто у меня итак все уже пестрит ими... Должно ведь быть еще что-то? Не может не быть!

← →
Skier (2003-08-28 13:53) [1]

Возьми на помощь Пятницу.

← →
stone (2003-08-28 13:55) [2]

Обычно сначала думают, долго думают, потом еще думают, а потом пишут код. У тебя, похоже, наоборот.

← →
VAleksey (2003-08-28 13:56) [3]

Опыт.
Напиши еще парочку подобных проектов.

← →
Dmitriy O. (2003-08-28 13:57) [4]

Используй Актион менеджера все разбей на логические процедуры понятно их обзови. Состряпай табличку в екселе. Используй блок схемы.

← →
Danilka (2003-08-28 14:02) [5]

не используй глобальные переменные. :))

← →
Rouse_ (2003-08-28 14:06) [6]

Во первых нужна модульность, каждый модуль отвечает за четко отведенную для него задачу. Не нужно писать все сразу, намного проще разбить задачу на подзадачи и выполнять их четко последовательно, с тщательной выверкой кода каждого модуля.
Ну и коментарии лишними конечно не будут, но не тупые коментарии типа
var
I: Word; // Переменная для цикла

а нормальные, типа описания для каждой процедуры и функции что она делает

Желаю успехов

← →
HolACost! (2003-08-28 14:08) [7]

Модульность - это как один из вариантов! второй - классность (если кто-нить понял, о чём я)!

← →
Dmitriy O. (2003-08-28 14:10) [8]

Модульность катит токо для сверх задач. Мелкие процедуры лутше хранить в менеджере.

← →
Rouse_ (2003-08-28 14:15) [9]

> HolACost! © (28.08.03 14:08) [7]

Классность как один из видов модульности.
Хотя я обычно все разбиваю по класам, как то удобнее работать становится.

Желаю успехов

← →
Delirium (2003-08-28 14:24) [10]

"объем исходного кода уже исчисляется несколькими тысячами строк, десятками юнитов, потоков, dll-ок" - это всё карточная игра? - Начинай сначала, такой объём кода не соизмерим с задачей, так часто бывает у новичков. Лучшее решение - начать заново. ;)

← →
HolACost! (2003-08-28 14:26) [11]

Не сказалбы - это один из подходов к программированию - гы - типа я 5 штук знаю!!! Типа Парадигмы программирования!

← →
Думкин (2003-08-28 14:26) [12]

Есть разные моменты:
Лтбо писать медленно - но качественно для потом...
Либо писать быстро и сейчас, но не читабельно.
Можно и с компромисом - но это опыт. А первое что желательно - как и сказано - ООП. Но в принципе, можно и без него - но рыбка из пруда легко не идет.

← →
Dmitriy O. (2003-08-28 14:33) [13]

Любая игра может занять скажем изначально N количество строк , если исходить что она много уровневая то если повышать ее сложность токо возможностями компа то N*10 типа как делают в дешевых играх стрелялках. Там усложнение задачи состоит токо в том противник бегает и скачет как угорелый и стреляет с математической точностью в степени уровня. Но если усложнение идет по принципу ИИ т.е. комп запоминает твои особенности игры то код может увеличится многократно т.е. N*1000.

← →
Lex (2003-08-28 14:37) [14]

"Обычно сначала думают, долго думают, потом еще думают, а потом пишут код. У тебя, похоже, наоборот."
Ты прав Stone: мне почему-то так легче, но если действительно лучше делать так, как говоришь ты - то я буду пытаться перестроиться. Я потому и спрашиваю: а КАК надо?

Skier > Пятница понимает только Робина из зоны... Может еще вспомним биографию Дэниэля Дефо?

VAleksey > "Опыт". Не мог бы ты поделиться своим?

Dmitriy O > Где он (Актион менеджер) находится? И как в блок схеме обозначить рекурсию? (а то я уже начинаю думать где мне достать лист формата А1 :))

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

Rouse > Согласен! Я стремился к тому, чтобы каждый модуль выполнял только свою задачу. Но у меня никак это не выходило, в ином случае приходилось передавать одному модулю такууую длинную строку фактических параметров... Неудобно одним словом. Да и то что я делаю тоже, признаюсь, неудобно. А если неудобно и то у другое - то мне и разнице нет :) Классы я конечно же использую, только не пойму как они могут помочь насчет сабже?

Извеняюсь если кому-то не ответил, просто ваши сообщения появляются быстрее чем у меня обновляется страница :)

← →
Jeer (2003-08-28 14:38) [15]

Dmitriy O. © (28.08.03 14:33) [13]

Чушь, извини за резкость.
А дельный совет от Delirium © (28.08.03 14:24)

← →
stone (2003-08-28 14:42) [16]

> Я потому и спрашиваю: а КАК надо?

Способов много. Если вкратце, проект условно делится на большие функциональные части, те, в свою очередь на более мелкие, и так до уровня необходимой детализации. Потом все это хозяйство анализируется, оптимизируется и т.д. Потом пишется ТЗ. Потом переходи непосредственно к кодированию.

← →
MsGuns (2003-08-28 14:43) [17]

>Dmitriy O. © (28.08.03 13:57) [4]
>Используй блок схемы

1.Блок-схемы укрупненные и подробные.
2.Блок-схемы
3.Еще раз блок-схемы.

Если лень рисовать и перерисовывать, кидай на фиг программирование сложных по логике вещей и иди че-нибудь администрить

← →
Dmitriy O. (2003-08-28 14:45) [18]

>Jeer © (28.08.03 14:38) Это по чему а может чел хочет мах воспроизвести манеру игры живого играка скажем префер. Там типа блеф , счет вышедших и ост карт анализировать стиль игры противника и выстраивать лутшею стратегию игры.
>Lex (28.08.03 14:37) Используй ActionList со стандарта или ActionManager с Аддитионал.

← →
Anatoly Podgoretsky (2003-08-28 14:51) [19]

Думкин © (28.08.03 14:26) [12]
Есть другой момент:
Писать быстро и качественно для потом и для сейчас и сразу читабельно и без ошибок, кроме типографских.

Но тут действительно нужен опыт.

← →
ZeroDivide (2003-08-28 15:00) [20]

>несколькими тысячами строк, десятками юнитов, потоков, dll-ок
>вдруг запускается поток,
А это действительно карточная игра :]

> и все это использует множество
>глобальных переменных, типов, которые описаные неизвестно где,
>непонятно зачем

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

← →
Skier (2003-08-28 15:02) [21]

>[14] Lex (28.08.03 14:37)
Ты не понял. ;)
Я имел ввиду что бывают такие проекты, которые одному просто не под силу сделать и никакие советы тут не помогут.

← →
Lex (2003-08-28 15:49) [22]

Delirium & Dmitriy O > Поэтому у меня так много и получается что я пытаюсь не просто научить компьютер играть по правилам, а еще и понимать игру соперника. Я конечно не могу его научить пользоваться интуицией (потому что ее у него нет и быть не может), но хочу научить подстраиваться под человека. Ведь у каждого своя манера игры - кто-то часто рискует, а кто-то предельно аккуратен. И моя цель - это именно его максимальный ИИ, но я никак не могу на нем сосредоточиться т.к. у меня в глазах - огромные стопки глобальных переменных. В чем еще можно хранить данные, которые останутся в памяти компьютера, а не обнулятся после выхода из процедуры как в случае с локальными переменными? Можно конечно использовать файлы, но это ведь нисколько не упрощает задачу. Поэтому-то в серьезных проектах одними функциями обойтись не возможно. Я конечно могу написать какого-нибудь "Дурака", но зачем он кому-то нужен если он действительно дурак. Тем более - в инете уже хватает откровенно тупых проектов того же "Дурака" - но это не мой уровень... И, уверен: тем более не ваш. А тех, кто говорит, что у меня слишком большая программа: попробуйте реализовать у себя в игре то, что пытаюсь реализовать у себя я. Я это говорю не в обиду себе и не в обиду вам. Я хоть и не продвинутый, но и не начинающий - в противном случае я бы не брался за эту программу и не просил помощи у вас, у БОЛЕЕ опытных. Хотя я уверен, что все можно сделать намного проще, но я делаю так как умею. Помогите мне и "Россия вас не забудет" :)

Stone> ТЗ - Терминатор З ? :) (просто в других конфах эта аббревиатура означала именно это, а то что имеешь ввиду ты, я не понял)

MsGuns> Мне не лень, я поэтому и говорю иду искать лист формата а1, и, наверное, в 2 экземплярах :). Также чертежные карандаши Т, ТП, ТМ, линейку, резинку, треугольник...

ZeroDivide> Если тебя удивляет поток, то он нужен для того, чтобы пока комп думал, юзер мог делать кое-какие действия в проге, а не сидел как пень :)

Anatoly Podgoretsky > Ты удивишься, но я так и пытаюсь делать. Потому что хочу как лучше, а получается...

Skier > В моем городе у меня просто не может быть помощников. Зато на нашем любимом сайте я надеюсь они будут.

P.S. Неужели тут все используют блок-схемы? Просто блок схемы еще 40 лет назад рисовали... Хотя я особо не растраиваюсь, в школе по черчению у меня пятерка был :)

← →
Е-Моё имя (2003-08-28 15:54) [23]

Lex (28.08.03 15:49)
зря самоуничижаешься
здесь много МЕНЕЕ опытных

ТЗ - Терминатор З
)))))))))))))))))
техзадание

← →
keymaster (2003-08-28 15:56) [24]

Использовать комментарии. В БОЛЬШОМ количестве....

← →
Vovchik_A (2003-08-28 15:56) [25]

Комментарии !!! Через 3 месяца глянешь в исходник и ужаснешься, если их не будет.

← →
Sandman25 (2003-08-28 15:59) [26]

Можно завести отдельные юниты с описанием типов и переменных, сгруппированных желательно по смыслу.
В качестве фактических параметров можно передавать var R: MyRecordType, тогда фактически передается только 1 указатель (нет большой платы за вызов функции), но увеличивается простота сопровождения.
Если есть несколько однотипных переменных, желательно их называть однотипно или использовать массивы. В общем, не нужно стремиться называть переменные в 2-3 символа. ИМХО лучше потратить 2 секунды на вставку переменной Player1Suit в буфер, чем потом мучиться вопросом, что же хранится в P1S.

PS. А что за игра, если не секрет?

← →
Danilka (2003-08-28 16:02) [27]

Lex (28.08.03 14:37)
>В больших программах очень трудно обойтись одними функциями - очень нужно >иногда обмениваться переменными между разными юнитами...

1. Обмен данными надо делать не между юнитами а между объектами.
2. Общие объекты проще всего хранить в DataModule, см справку по TDataModule.

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

← →
k-man (2003-08-28 16:10) [28]

> ТЗ

Если я не ошибаюсь Техническое задание
> Неужели тут все используют блок-схемы? Просто блок схемы
> еще 40 лет назад рисовали... Хотя я особо не растраиваюсь,
> в школе по черчению у меня пятерка был :)

Я использую блок-схемы. Намного удобнее думать на бумаге а потом приступать к кодированию. Если бы так делал полтысячи ненужных строк точно бы скосил. А может и больше. Я когда писал свой первый проект(тоже небольшую игрушку) то одна из процедур занимала около 300 строк.
Имела 4(!!!) вложенных цикла и как я ее отладил до сих пор ума не приложу.
А потом сел подумал взял лист бумаги и подошел к той же задачи совсем с другой стророны. Строчек стало 50 и цикл один. Теперь я всегда пользуюсь этим методом.
А что было по черчению это дело десятое.

← →
nikkie (2003-08-28 16:19) [29]

Совет - продумывать и проектировать перед тем, как кидаться программировать. Разбивать на модули, классы. Рисовать картинки.

Блок-схемы тут не очень подходят, если только в каком-то месте сложный алгоритм... В целом нужны что-то типа схемы взаимодействий классов, можешь почитать что-нибудь про UML и/или Rational Rose. Это правда целый отдельный мир, не меньше, чем мир Дельфи, но полезно хотя бы пробежаться и посмотреть, какие картинки предлагают рисовать. Из небольшого соприкосновения с этим я для себя уяснил прелесть только одного типа диаграмм, несколько раз использовал - было очень полезно. Имхо, строго следовать стандартам при рисовании картинок не обязательно, главное - чтобы картинки были понятны.

Не всегда все можно спроектировать до того, как начнешь программировать. Поэтому когда пишешь код, который приносит что-то новое по сравнению с оригинальным проектом - документируй свой код теми же сами картинками.

Несколько более мелких советов по написанию приличного кода
1. стараться поменьше использовать глобальных переменных
2. давать осмысленные названия переменным, хорошо бы использовать некие соглашения по именованию переменных (по-крайней мере локальные, глобальные переменные и члены класса должны отличаться с первого взгляда)
3. писать код структурно, разбивать на процедуры, не перегружать отдельные процедуры
4. комментировать

← →
VAleksey (2003-08-28 16:38) [30]

> Lex (28.08.03 14:37)

Мог бы.
Когда - то давно написал я одну программу. Понял что это работать не будет. Переписал ее снова. Не понравилось. Переписал третий раз. Третий вариант до сих пор работает и я так полагаю пока не устареет или нового не напишут - будет работать. :-)
Так вот походу этих переписываний у меня вырабатывались определенные правила, представления о том как надо, обзаводился своими модулями, которые потом использовал уже во всех проектах, приобретал знания и т.д.
НО есть большое НО. Я, наверное к сожалению, не могу писать "карточные игры" :-(. Т.е. все проекты, которые я делал, потом внедрялись. Это меня стимулировало. А игры писать ... не могу сосредоточиться.

> MsGuns © (28.08.03 14:43)

Е... Прислушайся к этому. Кстати, я тоже без блок-схемы, без модели объектов за проект не сажусь.

> Lex (28.08.03 15:49)

Блин, я вспомнил!!! На самом деле первый раз я программировал нечто вроде игры Bashe или 3-5-7 (по разному называют), как курсовую работу на 2-м курсе, по системам искусственного интеллекта! Самообучающуюся. Ага. На паскале. И помню, что так же запутался. В итоге переписал все заново, но уже описав, как говорил ранее, связи объектов и составил несколько блок-схем. Данные хранились в файле. А где же еще им храниться?
PS
Блин, прикольная игруха была... Жаль что потерялась.

← →
iZEN (2003-08-28 22:23) [31]

Мартин Фаулер "Рефакторинг: улучшение существующего кода".
Лучше, всё-таки, изучить ООП - оно помогает бороться со сложностью.

Тимоти Бадд "Объектно-ориентированное программирование в действии" - кстати, там есть неплохие примеры карточной и других игр в ООП-стиле.

И напоследок,
Эрик Гамма и др. "Приёмы объектно-ориентированного проектирования"

P.S. Думайте над архитектурой ежечасно, но не после реализации.
P.P.S. Книжки можно искать любым поисковиком (сходите на books.ru и piter.com).

← →
uw (2003-08-29 03:16) [32]

Непременное использование ООП.
Каждая сущность – класс. Если это кажется слишком, вспоминай про VCL – там все именно так.
Каждому классу – свой модуль. Но все же в модуле может быть и несколько близких друг другу классов.
Все типы, связанные с классом, - в модуле этого класса.
Предположим, пишешь обработчик пункта меню. Заниматься этим должен класс. Пусть хоть на это требуется всего один метод. В модуле, создающем класс, не заводи его переменную, лучше вызови классовый метод, который создаст объект, выполнит нужную функцию и уничтожит объект. В классе уже будет два метода, а переменная – в модуле класса.
Если класс создается из разных потоков, заботиться о механизмах разделения ресурсов типа критических секций или мьютексов должен сам класс.

Честно говоря, блок-схемы мне никогда не помогали, даже когда писал десятки тысяч строк на ассемблере. Я научился обходиться без них, но при этом должна быть безупречная структура каждого метода или подпрограммы по типу:
ЗайдиНаКухню;
ВключиСвет;
ВскипятиВоду;
ЗавариЧай;
И т.д. Потом реализуешь эти методы. Как только начинаешь скрипеть зубами от усложнения алгоритма, создавай новый метод (или вложенную подпрограмму) и вызывай ее.
Все идентификаторы – максимально информативные. Комментарии – к сложным алгоритмам, не понятным с одного взгляда. Но алгоритмы должны быть понятными и без комментариев. Например, если ты анализируешь слова из текстового файла, то внешний цикл должен вызывать процедуру GetWord, та для формирования слова – GetChar, а уж только та может лезть в файл (может быть, не сразу, а через буфер); но не наоборот: читаем из файла зачем-то в цикле символы, из них составляем слова и т.д.

UML мне тоже не помог, хотя принципом «каждая сущность – класс» проникся. Но, возможно, в том, что я не научился пользоваться UML, сказалась многолетняя привычка и, как следствие, - косность.

Чтобы не было пауз и чтобы не забывать, что где находится, нужно вводить себя в состояние потока и думать только о программе все время. Первый вариант не обязан быть оптимальным: писать нужно быстро и так, чтобы работало. Если потребуется ускорение, то потом можно улучшить алгоритм, а если нет – больше к нему возвращаться не надо. Нужно быть жестким к сотрудникам и родным – любое обращение к тебе выбьет тебя из состояния потока минимум на 10 минут. Если программа требует от тебя десяти месяцев непрерывной работы, то ты должен работать 10 месяцев с утра до ночи без выходных и отпусков. Если у тебя появляется сомнение в правильности такого поведения – брось программирование, и ты поступишь правильно, потому что нет более гадкой профессии, т.к. она сушит мозги, и даже когда ты закончишь программу, и она будет классно работать, то ты получишь скорее не удовлетворение, а опустошение.

Но все это ИМХО :)

← →
iZEN (2003-08-31 00:30) [33]

uw © (29.08.03 03:16) [32]
Каждая сущность – класс. Если это кажется слишком, вспоминай про VCL – там все именно так.
Не надо доводить до абсурда. Сущность может НЕ БЫТЬ классом. Например, содержимое текстового редактора - текст - скорее всего, отображения одного, но параметризованного, объекта, спроектированного по паттерну Flyweight (представьте себе, что каждая буква в документе будет объектом - посмотрим, сколько этот документ будет занимать памяти и как долго он будет обрабатываться :-).
VCL - пример НЕУДАЧНОЙ реализации библиотеки виджетов.
Предположим, пишешь обработчик пункта меню. Заниматься этим должен класс. Пусть хоть на это требуется всего один метод. В модуле, создающем класс, не заводи его переменную, лучше вызови классовый метод, который создаст объект, выполнит нужную функцию и уничтожит объект. В классе уже будет два метода, а переменная – в модуле класса.
Например, класс паттерна проектирования Command. ;)
Если класс создается из разных потоков, заботиться о механизмах разделения ресурсов типа критических секций или мьютексов должен сам класс.
Поправочка: используется, а не "создаётся" (создание экземпляра, как правило, - атомарная операция).
Надо признать, в Delphi очень слабо организована многопоточность - слишком много усилий требуется для потокобезопасного использования кода.
Потом реализуешь эти методы. Как только начинаешь скрипеть зубами от усложнения алгоритма, создавай новый метод (или вложенную подпрограмму) и вызывай ее. Все идентификаторы – максимально информативные.
Эх... Наследсво ассемблера и Фортрана (Алгола): структурное программирование. ;)
UML мне тоже не помог, хотя принципом «каждая сущность – класс» проникся. Но, возможно, в том, что я не научился пользоваться UML, сказалась многолетняя привычка и, как следствие, - косность.
А, это - те картинки на обёрточной бумаге, что мы рисовали для себя, чтобы потом выкинуть?... :))
Или Together/RationalRose - как печка, от которой пляшут? ;)
(Не заморачивайтесь, есть много способов построить UML-диаграммы, в том числе по исходникам).
Чтобы не было пауз и чтобы не забывать, что где находится, нужно вводить себя в состояние потока и думать только о программе все время.
Прямая дорога в психушку.
Нужно делать код "разрывным" - это когда всё уже работает на начальной стадии проектирования, потом постепенно дописываются и интегрируются другие части. Ясная картина архитектуры системы - вот главное и незабываемое.
Нужно быть жестким к сотрудникам и родным – любое обращение к тебе выбьет тебя из состояния потока минимум на 10 минут.
Это - вопрос организации рабочего места.
Если программа требует от тебя десяти месяцев непрерывной работы, то ты должен работать 10 месяцев с утра до ночи без выходных и отпусков. Если у тебя появляется сомнение в правильности такого поведения – брось программирование, и ты поступишь правильно, потому что нет более гадкой профессии, т.к. она сушит мозги, и даже когда ты закончишь программу, и она будет классно работать, то ты получишь скорее не удовлетворение, а опустошение.
Ну уж таким путём идти, действительно - только в психушку.

Если ты видишь, что твоя программа, которую ты растишь как ребёнка, работает с каждым днём всё лучше и лучше - это незабываемое впечатление. Твоя самооценка повышается. Ты работаешь в удовольствие!

← →
uw (2003-08-31 01:25) [34]

>iZEN © (31.08.03 00:30) [33]

Не будь занудой, дай человеку самому разобраться, как не надо делать! Как надо - в книжках написано ;)

← →
Ketmar (2003-08-31 01:35) [35]

>#33
>представьте себе, что каждая буква в документе будет объектом - посмотрим, сколько этот документ будет занимать памяти и как долго он будет обрабатываться
а ведь так и есть %-) правда, я как-то позабыл умный термин Flyweight: ссылочку на книжку про паттерны не дадите? а то читал давно, не помню...

>VCL - пример НЕУДАЧНОЙ реализации библиотеки виджетов
согласен. идеологически неудачная. но приходится с ней работать, увы.

2Автор_вопроса: %-)
блок-схемы -- нафиг. места много, толку -- мало.
UML... не знаю, не использую. видимо, то, что у меня называется "общей схемой проекта", является неким подвидом UML.
ООП -- рулит %-) если умеешь правильно выстраивать иерархию классов.
модульность, конечно. модули -- максимально изолированные. если не получаются -- пересмотреть дизайн.
ну и не забывать на пиво периодически ходить да с девушками отвлекаться. иначе -- таки да, готовый пациент "жёлтого домика".
иногда полезно бросить проект на некоторое время. чтобы мозги смогли найти новые подходы.

← →
anpsoft (2003-08-31 01:54) [36]

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

Поясню на примерах.

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

У вашей программы 3 формы. Нет проблем.
У вашей программы 100 форм, опять вам в таком случае выгодней создать универсальный загрузчик форм, а к нему генератор форм а то и парсер скриптов по обработке этих форм.

Вы пишете вручную обработчик для ini файлов. Нет проблем.
Вы пишете обработчик для pascal-подобного скрипта своего генератора форм, тут уже лучше не писать всё это вручную а использовать yacc+lex, или подобные более совершенные программы-генераторы компиляторов, которые или создадут сами код для вас или поместят логику во внешние бинарные файлы. Вы же просто подцепите библиотеку по обработке этих файлов.

Ну и так далее.

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

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

Все это конечно труднее придумать и продумать, но намного интереснее, и намного меньше будет критического кода.

Попробуйте быть линивей :) Не пишите все в лоб, а лучше создайте виртуального программиста который будет делать за вас всю вашу черновую работу :) Тогда и программа станет надежней, и у вас будет время и здоровье потратить то что вы на ней заработаете.

← →
Ketmar (2003-08-31 03:53) [37]

согласен. только по поводу "генераторов компиляторов" поспорю, как не один год уже имеющий опыт создания компилеров/скриптовых языков. генераторы -- нафиг. кроме как руками -- неинтересно и непонятно %-)

← →
dmitry99 (2003-08-31 07:31) [38]

> Lex (28.08.03 13:49)

ООП + UML + пиво и девушки...

← →
Real (2003-08-31 09:52) [39]

> Неужели тут все используют блок-схемы? Просто блок схемы
> еще 40 лет назад рисовали...
А языку Си интересно сколько уже?

Предлагаю Лекса наградить медалью "Мастер Орешника"

З.Ы. Надеюсь, фишка про третьего терминатора уже там?

← →
Lexxx (2003-09-01 13:59) [40]

2Real >
Причем здесь си?
"Предлагаю Лекса наградить медалью "Мастер Орешника""
Лучше создать графу "Непонимающие юмора" и поместить туда тебя.

2всем остальным>
Не увидя свою ветку на первой странице, я уже начал обдумывать, переваривать и пересображать все то что вы мне насоветовали... Но случайно нажал на кнопку обновить в своей опере и увидел еще пару интересных постов. Спасибо всем.
Также большое спасибо uw&iZEN - вы вместе все довольно учачно растолковали, теперь можете со спокойно душой идти пить пиво. Что, думаю, за прошедшие два дня вы сделали не раз :)

P.S. iZEN> Пытаюсь найти указанные тобою книги: книгу Т. Бадд. я в html нашел на питере, а вот с Фаулером проблемы... Не знаешь где найти ее в электром варианте? А то она больно дорогая получается... Иль может у тебя сканер хороший? :)
P.P.S. Lexxx - все, теперь мне придется быть с тремя иксами. Кто-то оказался проворнее и зарегистрировался под моим ником первее... Жалко...

Как не запутаться в коде? Найти похожие ветки