在Simulink中，Goto和From街区通常被认为是糟糕的风格吗？
我最近在研究一个Simulink模型，并且使用Goto和From块来防止一个非常繁忙的系统变成一堆扭曲的杂乱的电线。我被告知，我不能使用Goto和From块，因为它们被认为是糟糕的风格(至少，据我的雇主说)。
虽然我认为应该尽可能地保持连接，但是我相信如果模型会导致大量交叉线，那么Goto和From块可以显著提高系统/子系统的可读性；特别是如果这些块可以进行颜色编码(例如，紫色Goto块用于所有的紫色From块)。
我会提供我正在处理的子系统的映像，但是我不确定我能不能把它放在这里。子系统本身有大约12个子系统块(可能更晚一些)，每个子系统都有两个总线类型的输出。每个子系统的第一个输出转到一个Bus Creator块，每个子系统的第二个输出转到第二个Bus Creator块。由于子系统是垂直对齐的，而Bus Creator是在右边对齐的，因此会产生许多交叉线。我使用Goto和From块来清理系统。
我可以提供一个更小的，但类似的模型，我把这个问题放在一起。
对于一个有12个子系统的系统来说，这变得非常繁忙。我使用Goto和From块来连接子系统和Bus Creator，而没有过多的交叉线。
我相信，我的雇主可能对使用基于文本的语言的goto语句并将其应用于Simulink中的Goto/From块带来了耻辱。一般来说，以这种方式(或任何方式)使用Goto和From块是否被认为是糟糕的风格？
回答 1
Stack Overflow用户
发布于 2013-11-25 22:37:25
Mathworks汽车咨询委员会已经发布了一些建模指导方针 (PDF)，其中包括使用Goto/From。他们列出的规则如下：
- 没有浮动的子系统，即所有的输入/输出端口都是通过
Goto连接起来的。Simulink的一大优点是能够通过粗略的视觉检查来确定信号流，不要通过将所有东西都连接到Gotos来破坏这一点。至少有一个前馈和一个由信号线连接的子系统之间的反馈回路。
- My personal opinion on feedback signals is that they should all be connected with signal lines, but I'm sure you can come up with cases where drawing all of them clutters the model.
- 第二个准则是关于
Goto标记的范围；尽可能保持可见性local。
- I feel setting visibility to `scoped` is acceptable also as long as you're not using the matching `From` more than a couple of levels downstream from the `Goto`. I've yet to come across a legitimate need for a global `Goto` tag.
所以，所有的Goto使用都不错，而且在某些情况下它可以提高可读性。尽管如此，我不认为Gotos对上面的图片是有道理的。我意识到这只是一个例子，但我应该指出，如果正在创建的总线是虚拟的，那么创建者输入的顺序并不重要，重新安排Bus Create和Mux块输入可以提高可读性。
上面的指导原则的问题是，有弯曲它们的空间，而您的团队中的开发人员可能就是这样做的。即使每个人一开始都很努力地遵循这些准则，但从现在起很长一段时间内，当您重新绘制模型的该部分以改进/添加功能时，您可能会违反这些准则。重新安排输入和输出在实现一些很酷的新功能的过程中可能特别令人恼火。这可能就是你的雇主选择实行全面禁令的原因。这在某些情况下是不方便的，但更容易执行。
https://stackoverflow.com/questions/20204253
复制相似问题
腾讯云开发者
