结构规则。 学习如何构建方案，探索可能性、错误、解决方案等。
来自"bug, bugs, questions"分支。
设计之初的一个非常典型的问题：如何组织（结构化）程序中的事件处理，使其（程序）能够进一步发展，同时将已经完成的事情重做到最小。
你想讨论选择吗？
是否有任何文献资料，比如说？
我是在纸上画的，所以对我来说比较方便，有时要花50张纸，直到做出一个清晰的结构。当然可以在spets.editors中，但他们每个人都让我感到不舒服（有限），不可能实现幻想的飞行，总之，减缓了工作。
- ru.wikipedia.org
我有一个最简单的选择
int main() { while ( !IsStopped() ) { switch ( GetEvent() ) { case TIMER : case BUTTON : case LISTVIEW: case CALENDAR: case CLOSE : case ERROR : default : } } }
结构是什么意思？
ZS：我是这样被教育的。
1.所有你能做的事情都在一个函数中。
2.得到是一种罪
3.所有的条件都必须是最小的，一个条件不能有任何重叠
4.3.缩进
5.一个人必须以这样的方式来写，别人可以在你之后阅读它
6.清晰而有意义的变量名称
7.评论，但不要过度
像这样，但又不完全像这样:http://korzh.net/2011-03-pravila-xoroshego-tona-v-programmirovanii.html
- korzh.net
先到先得 :)。你为什么不先告诉我们它对你来说是什么样子？
嗯，我怀疑会是这样的情况......))
好吧，我没有什么好隐瞒的（就结构化而言），我不怕讨论。
但我不建议你立即假设或草率批评--我不假设我的决定是 "模范的"，甚至是任何一种和谐--在它们的质量上，它们不是特别有根据的，是由同样的 "宗教 "因素产生的--习惯、"书本真理"、论坛文章、标准终端交付的样本和其他自发聚集在脑子里的垃圾。 我有一些发现，但没有太严重的。
首先，我想提出几个方便的术语，以便减少混乱（我怀疑会有很多混乱）。
1) 物理项目 结构： 文件、文件夹和其他实体的组织，在项目的 "外部 "视图中可见。
2) 项目的逻辑结构：组织所有 "内部 "软件的东西 - 变量、函数、类、协议等。
-----------------
我的mql-projects的物理结构是非常简单和原始的。我有意识地尝试这样做，以减少混乱，并将可能出现的混乱的后果降到最低。
作为一项规则（对于一个中等规模的），它是一组.mqh文件（安排在适当的文件夹中）+一个mq5文件。
// 如果系统是多线程的（例如，在最简单的情况下，专家顾问+指标）-那么mq5文件的数量与项目中的程序数量相对应。
我尽量不使用(.ex5)库。//非常有争议的决定，但我这样做是为了尽量减少运行时问题。
--
我暂时不对逻辑项目结构进行评论--这个主题非常大，我需要屏住呼吸......:)
我尽量不使用libs(.ex5)。//这是一个非常有争议的解决方案，但我这样做是为了尽量减少运行时问题。
我试图把任务作为一个整体来设想，并确定构成任务的主要对象。
然后，我把对象划分为组件，寻找组件中的交叉点，然后出现祖先对象。
事情就是这样的。
如果我在一个项目中发现了我以前见过的对象实体，我会试着把以前验证过的代码包括进去。
从最简单的程序到复杂的软件包。
--
我敦促专家们支持这个主题。
我理解一个主题的广度和它的 "宗教指控"（*），以及因此可能产生的混乱和潜在的冲突的分支。
尽管如此，我还是请求大家支持，因为每个人都能从中受益--明智的（具有高潜力的）想法经常在垃圾堆中被发现，人们只需要能够注意到并及时 "掌握"。
----
(*) 这里所说的 "带宗教色彩"，我理解为程序员的程序结构往往是建立在习惯、传统和文学的基础上，而完全不是建立在对自己和其他人（例如，未来的合著者）的常识和预期的真正便利上。