In Simulink, Goto and From blocks are usually considered bad style?

Question

I recently worked on a Simulink model and used the Goto and From blocks to make the system very busy due to twisted wires. I was told that I should not use the Goto and From blocks, as they are considered bad style (at least according to my employer).

While I believe that wires should be connected whenever possible, I believe that the Goto and From blocks can significantly improve the readability of the system / subsystem if the model leads to a large number of cross wires otherwise; especially if the blocks can be color coded (for example, the purple Goto block goes to all the purple From blocks).

I would put the image of the subsystem with which I work, but I'm not sure that I can put it. The subsystem itself contains about 12 blocks of subsystems (and, possibly, later) inside them, each of which has two outputs on the bus. The first output of each subsystem goes to the Bus Creator block, and the second output of each goes to the second Bus Creator block. Since the subsystems are vertically aligned and the Bus Creator is to the right, this leads to many cross-wires. I used the Goto and From blocks to clean the system.

I can provide an image of a smaller but similar model that I put together for this question. For a system with about 12 subsystems, it becomes very busy. I used the Goto and From blocks to connect the subsystems and Bus Creator without a lot of cross wires.

I believe that my employer can bear the stigma when using Goto operators from text languages ​​and apply it to the Goto / From blocks in Simulink. Generally speaking, does Goto and From blocks in this way (or in any way) that are considered bad style?

Answer 1

The Mathworks Automotive Advisory Board has published some modeling guidelines (PDF) that include the use of Goto / From . The rules they list are:

• They do not have subsystems that float, i.e. All inputs / outputs are connected via Goto s. One of the great features of Simulink is the ability to determine the signal flow only with the help of surface visual control, without destroying it, connecting everything with Goto s. At least one feedback channel and one feedback loop between subsystems connected by signal lines.

  • My personal opinion on feedback signals is that they should all be connected to signal lines, but I'm sure you can come up with cases where they all clutter up the model.
    
    

• The second recommendation concerns the area of ​​the Goto tag; keep local visibility as high as possible.

  • I feel that setting visibility to scoped acceptable as well unless you use a matching From more than a few levels downstream of Goto . I have yet to find a legitimate need for a global Goto tag.

So, all the use of Goto not so bad, and you are right that in some cases it can improve readability. That being said, I do not think that Gotos is justified for the picture above. I understand that this is just an example, but I must point out that if the buses being created are virtual, then the order of the inputs from the creator does not matter, and rearranging the Bus Create and Mux inputs can work wonders for readability.

The problem with the above recommendations is that there is room for them to bend, and the developers on your team can do this. Even if everyone tries to follow them at the beginning, you may come across these recommendations one day, a long time from now, when you redraw this section of the model to clarify / add functionality. Reorganizing inputs and outputs can be particularly annoying in the middle of implementing some kind of new new feature. This may be the reason that your employer has decided to impose a complete ban. In some cases, this is inconvenient, but easier to provide.