Структура рулит. Учимся структурировать программы, изучаем возможности, ошибки, решения и т.п.
Структура рулит. Содержание вторично, структура первична.
У меня "Панель" - структура простейшая: Событие -> Обработка
События тоже простые: нажатие кнопки, выбор списка, календаря, перемещение мыши и т.п.
Весьма типичная проблема для начала проектирования: как бы так организовать (структурировать) обработку событий в программе, чтобы её (программу) в дальнейшем можно было развивать и при этом минимально переделывать уже сделанное.
Хотите обсудить варианты?
Из ветки "Ошибки, баги, вопросы" :
Весьма типичная проблема для начала проектирования: как бы так организовать (структурировать) обработку событий в программе, чтобы её (программу) в дальнейшем можно было развивать и при этом минимально переделывать уже сделанное.
Хотите обсудить варианты?
А есть для например какая нить литературка?
Вообще вопросы проэктирования перекликаются с САПР и ТРИЗ.
ЗЫ Я рисую на бумаге, мне так удобнее, иногда до 50 листов уходит пока чёткая структура вырисовывается. Можно конечно в спец.редакторах но каждый из них для меня неудобен (ограничен), невозможно воплотить полёт фантазии, короче тормозят работу.
- ru.wikipedia.org
У меня самый простой вариант
int main() { while ( !IsStopped() ) { switch ( GetEvent() ) { case TIMER : case BUTTON : case LISTVIEW: case CALENDAR: case CLOSE : case ERROR : default : } } }
что понимается под структурой?
ЗЫ: меня учили так:
1. всё что можно в функции выноси м в функции
2. goto грех использовать
3. все условия должны быть минимальны и в одном условии не должно быть пересечений
4. 3 отступа
5. писать так что бы после тебя можно было разобрать другому
6. понятный и осмысленные названия переменных
7. комментарии, но не переусердствуй
вот типа того, но не совсем то: http://korzh.net/2011-03-pravila-xoroshego-tona-v-programmirovanii.html
- korzh.net
А есть для например какая нить литературка?
Вообще вопросы проэктирования перекликаются с САПР и ТРИЗ.
ЗЫ Я рисую на бумаге, мне так удобнее, иногда до 50 листов уходит пока чёткая структура вырисовывается. Можно конечно в спец.редакторах но каждый из них для меня неудобен (ограничен), невозможно воплотить полёт фантазии, короче тормозят работу.
САПР не совсем то, всё же это автоматизированное проектирование.
ещё перед написанием программы учили делать наброски на бумаге, упрощённый алго язык, но я так к нему и не привык.
Кто первый, тому и водить :). Начните что ли, расскажите как это выглядит у вас?
Ну я подозревал что так будет... ))
Хорошо, мне скрывать особо нечего (в плане структурирования), обсуждения не боюсь.
Но не советую сходу брать за образец или наоборот поспешно критиковать: абсолютно не предполагаю "образцовость" или даже какую-либо гармоничность своих решений - в своей массе они не особо основательны и порождены теми же "религиозными" факторами - привычками, "книжными истинами", форумными статьями, образцами из стандартной поставки терминала и прочего стихийно-собранного мусора в голове. Есть некоторые свои находки, но ничего особо серьёзного.
Для начала хочу предложить ввести в обиход парочку удобных терминов, дабы меньше путаницы в ветке создавалось (подозреваю что её будет много).
1) Физическая структура проекта: Организация файлов, папок, и прочих сущностей видимых при взгляде на проект "снаружи".
2) Логическая структура проекта: Организация всей "внутренней" программной лабуды - переменных, функций, классов, протоколов и тд. и пр.
-----------------
Физические структуры mql-проектов у меня весьма просты до примитивизма. К этому сознательно стремлюсь, дабы уменьшить путаницу и минимизировать последствия возможной путаницы.
Как правило (для средненьких по размеру) это множество .mqh файлов (разложенных по соответствующим папкам) + один mq5-файл.
// Если система мнопоточная (к примеру в простейшем случае советник + индикаторы) - то количество mq5-файлов соответственное количеству программ в проекте.
Либы (.ex5 ) стараюсь не использовать. // Очень спорное решение. Но я действую так, дабы минимизировать проблемы времени выполнения.
--
Про логические структуры проектов пока воздержусь - тема очень большая, нужно хоть дух перевести... :)
САПР не совсем то, всё же это автоматизированное проектирование.
ещё перед написанием программы учили делать наброски на бумаге, упрощённый алго язык, но я так к нему и не привык.
Я пытаюсь представить задачу в целом, и выделить основные объекты из которых состоит задача.
Затем разбиваю объекты на составляющие, ищу в составляющих пересечения тогда появляются объекты-предки.
Как то так.
ЗЫ если в проекте нахожу объектные сущности которые ранее уже встречались стараюсь подключать старый выверенный код.
ЗЗЫ Если вы говорите об оформлении, то достаточно перестать бодаться и принять стиль MQ, тогда нажатием одной кнопки стайлер у всех будет один стиль и всё всем будет понятно.
Либы (.ex5 ) стараюсь не использовать. // Очень спорное решение. Но я действую так, дабы минимизировать проблемы времени выполнения.
Я пытаюсь представить задачу в целом, и выделить основные объекты из которых состоит задача.
Затем разбиваю объекты на составляющие, ищу в составляющих пересечения тогда появляются объекты-предки.
Как то так.
ЗЫ если в проекте нахожу объектные сущности которые ранее уже встречались стараюсь подключать старый выверенный код.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Начиная с простейших программ и заканчивая сложными программными комплексами.
--
Призываю профи поддержать эту ветку.
Понимаю необъятность темы и её "религиозную заряженность" (*) , а следовательно возможную сумбурность и потенциальную конфликтность ветки.
И тем не менее прошу поддержать, ибо своя польза может быть у каждого участника - толковые (с высоким потенциалом) идеи зачастую встречаются в кучах мусора, нужно только суметь заметить и вовремя "прибрать к рукам".
----
(*) Под "религиозной заряженностью" в данном контексте понимаю тот факт, что структуры программ программистами зачастую строятся на привычках, традициях, и литературных источниках, а вовсе не на здравом смысле и ожидаемых реальных удобствах для себя и прочего населения (например будущих соавторов).