Большой проект - и без ошибок?

Итак, начинаю новый проект.
Сначала дело "летит". всё легко и понятно.
Но вот программа разрастается.
Постепенно в процессе работы в руках появляется авторучка, и на клочке бумаги появляются первые аккуратные столбики с записанными переменными.
Вскоре столбики перестают быть аккуратными, а бумажек становится несколько. И вот раздаётся "первый звоночек" - смотрю на процедуру и не понимаю - а что это вообще такое?
Возвращаюсь по коду и смотрю...

Дайте грамотный совет - как разбить программу на куски (что-ли...)
или кто как создаёт большие проекты без путаницы? Поделитесь опытом.

 

1) Процедуры должны быть по возможности автономными. Это упростит отладку и даст возможность использовать их в других проектах.
2) Используй локальные переменные и метки.
3) Попробуй использовать IDE. Вот тема была

 

1. Комментарии
2. Использовать "говорящие" имена переменных, меток и процедур.
3. Если ты пишешь на асме, то желательно пользовать регистры по их назначению, т.е. есх - для счетчика или индексации, esi & edi для указателей на структуры и буфера и т.д.

 

RadAsm в руки.
Есть список:
процедур, переменных, структур, меток ...
Можно коменты написать к каждой:
переменной, метке, структуре, прочедуре...

Навигация по коду.
Ткнул на переменной, метке, структуре, прочедуре... и перешел к месту ее объявления.
Удачи.

 

ax - аккумулятор
bx - база
cx - счётчик
dx - данные

si - смещение входных данных
di - смещение выходных данных

bp - смещение на локальных переменных и параметров

 

Имя модуля - это имя файла. Например, в файле "String.Asm" - находится всё, что связано с операциями на строках. В самом файле, каждая процедура с префиксом модуля:

String_RemoveChars
String_ReplaceChars
String_Parse
...

Единство имён очень важно. Например, если есть такой объект: TWindow, значит необходимо иметь такие файлы:

TWindow.Inc - описание структуры TWindow и сопутствующих констант или макро-расширений.
TWindow.Asm - описание кода для работы с объектом (опять же с префиксами "TWindow_").

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

 

Mikl___
Многабукофф

Обычно принято dx:ax, edx:eax

Обычно принято al, ax, eax

Ещё форматирование кода помогает (если формат удобен для ТЕБЯ).

 

TOLSTOPUZ

Сильно зависит, какие средства для этого предоставляет язык, на котором пишешь.

 

Опыт, опыт и только опыт...
Помимо того, что уже написали:
-каждая процедура должна выполнять только одну функцию (doThisAndThatAndSomethingElse - неприемлемо!
-у тебя не должно быть длинных процедур - если она длинная, значит ее наверняка можно разбить на несколько коротких.
-зависимости между разными кусками кода должны быть минимальны и четко видны. Нужно не использовать глобальные переменные, если их можно заменить локальными. Нужно делить код на модули, каждый из которых отвечает за какую-то часть логики программы и имеет *четко выраженный* интерфейс для работы с ним
-как уже писали выше, комментируй каждый модуль и процедуру, это для асма особенно важно.
-используй общий стиль именования переменных, комментирования и соглашений по программированию для всего проекта(в частности, как писали выше, одни и те же регистры для входных и выходных данных процедур)
Если кратко, то максимальная инкапсуляция и документирование.

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

Очень рекомендую "4 бандитов" - Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес Приемы объектно-ориентированного проектирования. Паттерны проектирования. Даже если ты не знаешь С++, то хотя бы поймешь, к чему нужно стремиться при проектировании программы, чтобы она оставалась стабильной и понятной через любое время после начала ее разработки

ЗЫ: Помни, что настоящий программист ленив - настолько ленив, что пишет код аккуратно и комментирует его, т.к. ему потом лень будет разбираться в том, что он понаписал =)
ЗЗЫ: нужно понимать, что красивые отступы, пробел после запятой, a = b + c вместо a=b+c нужно прежде всего тебе.
ЗЗЗЫ: если хочешь запости какой-нибудь свой "развалившийся" проект, тут найдется много желающих его раскритиковать

 

т.е. к примеру

Код (Text):

1. Процедура_0
2.   действие 1
3.   действие 2
4.   действие 3
5.   действие 4
6. конец

нужно разбить на

Код (Text):

1. Процедура_1
2.   действие 1
3.   действие 2
4. конец
5.  
6. Процедура_2
7.   действие 3
8.   действие 4
9. конец
10.  
11. Процедура_0
12.   Процедура_1
13.   Процедура_2
14. конец

?

 

K10
Не совсем
Если процедура выполняет 4 независимых действия - то ее следует разбить на 4 процедуры
На практике почти не бывает случаев, когда процедура на ЯВУ занимает больше экрана и при этом ее кусок нельзя вынести в виде отдельной процедуры с осмысленным именем, параметрами и сутью

 

Процедурное программирование при разработке больших проектов использовать нецелесообразно. Даже если проект пишется на процедурном языке, всё равно лучше делать в стиле ООП. Основной принцип ООП это инкапсуляция, пишите библиотеки, модули, скрывайте в них то, чего не нужно видеть остальным частям проекта. Старайтесь как можно меньше делать зависимостей по данным, используйте описатели вместо указателей. Делайте функции манипулирующие сущностями. Например в винде доступа к данным окна нет, есть только методы позволяющие манипулировать им. Так что абстракция и инкапсуляция спасут отца русской демократии. ^)

 

TOLSTOPUZ
Я так думаю что ты уже много написал? И тебе все это надо разбить на части? Читал про автоматы? Там сложность схемы оценивается по количеству входов. Также и в программах - чем больше вызовов функций, ветвлений и циклов тем запутанней программа. Уменьшение сложности программы:
1) Раздели интерфейс и вычислительную часть друг от друга (если раньше не разделил)
3) Запиши в отдельные части никак не зависимые фрагменты программы (функции которых друг из друга не вызываются).
3) Перемести в отдельные модули функции, общие по назначению (если 2 функции работают с жирафами, то они должны быть в одном модуле "Работа с жирафами").
4) Делай меньше вызовов пользовательских функций (это те, которые ты написал и они определяют алгоритм программы, а не strcmp или printf). Одна пользовательская функция должна вызывать 1-2 других пользовательские функций.

 

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

 

От путаницы есть стандартные решения:
1 язык высокого уровня
2 ООП
3 design patterns
т.е. всегда строго по пути повышения уровня

Большой проект без ошибок быть не может.
Однако, от них тоже есть стандартные средства - QA

 

Дабы не создать лишнюю тему, хочу поинтересоваться у умудренных опытом воинов дзена здесь =)

Какие средства проектирования ПО и БД кто использует и почему.
Я конечно понимаю, что есть Rational Rose, но 5 - 10 к зеленых платить хочется.
Поэтому юзаю Umbrello UML modeler в KDE, так как бесплатен.
Не хочется время и деньги тратить на изучение другого ПО, хочу услышать кто чем пользуется - все за и против. Платформа не принципиальна.

 

Реально хорошее средство проектирования пока, к сожалению, только одно - мозг
Поэтому - бумага и карандаш Недорого и вполне работает.