Structorizer.Desktop
Structorizer.Desktop copied to clipboard
fesch
[FR]: Add option to include a framing item
We currently have only one framing item, the program/sub. Adding the option to create a framing item (which can include any other elements) would be nice for "grouping" logical parts within the NSD, named or not with an optional comment and could be used by the generators for generating braces (for code folding, variable scope, ...)
It even could be used for representing a named target for JUMP instruction (or is there an option to do this already?).
It even could be used for representing a named target for JUMP instruction (or is there an option to do this already?).
No, and there won't be as long as I can hinder it. A labeled JUMP has nothing to do with structured programming and is by very good reasons banned. If you want to generate spaghetti code, then use a flow chart (PAP) editor, please. Generators for certain languages must use jump labels to support some leave / break / exit construct, which is already borderline. But I see no way to resolve labelled jumps on import. And there won't be NSD elements for them. It's simply contradicting the intention of NSD and reliable programming. Structorizer shall help users to learn how to avoid such crap programming.
In order to mark certain subsets of an algorithm you could use colouring. Well, it's going lost on export, of course, but subframes are functionally irrelevant, anyway, since Structorizer doesn't know the concept of block-local variable scope. Students should better think about using subroutines in these cases. So I tend to reject this proposal. Structorizer has gained some properties of IDEs already but it's not the aim to make it as mighty and overwelming as VisualStudio or as our dinosaur programming language... :wink:
Maybe I misunderstood the instruction that is labeled "JUMP"?
The import was actually my thought, too - what should happen on a goto? (I don't want to create it and would vote for "always mark this stuff red").
For the framing: given the Messwertstatistik5 sample you have a "block comment" STANDARDABWEICHUNGSBERECHNUNG which is obviously a comment for the instruction where it is placed and the instructions below. Would you place this part into a subroutine?
BTW: What is the fastest way of moving these parts into a new subroutine?
Maybe I misunderstood the instruction that is labeled "JUMP"?
Maybe. The JUMP elements are actually EXIT actions, they may leave a loop (leave/break), a routine (return) or the entire program (exit). This is the utter concession to unstructured programming acceptable in a structogram.
The import was actually my thought, too - what should happen on a goto? (I don't want to create it and would vote for "always mark this stuff red").
The goto instruction would either be ignored or put as "facsimile" into a disabled element. May the user try to find a way out of his dilemma himself. Import of break, return and exit instructions is no problem since Structorizer supports them all. The only difficulty are the C-typical break instructions delimiting the case scope in switch instructions. They must be ignored in switch context - unless its preceding case is neither empty nor terminated. There is an easier and a more complicated but more elegant way: The easier way means to duplicate the code of the terminated case, the more elegant way would try to merge both cases but insert an Alternative making the part before the confluence point conditional. By now I implemented the easier way.
For the framing: given the Messwertstatistik5 sample you have a "block comment" STANDARDABWEICHUNGSBERECHNUNG which is obviously a comment for the instruction where it is placed and the instructions below. Would you place this part into a subroutine?
Rather not - too tiny - but possible, with the advantage to be separately usable in cases where the average is already known.
BTW: What is the fastest way of moving these parts into a new subroutine?
While a copy and paste among Structorizer instances of the same process hasn't been implemented (should be pretty easy), you could do the following: Save the current diagram and push it to the Arranger, if you like. Then copy or cut the elements to form the subroutine. In the latter case you fill the gap with the subroutine call immediately. Save again. Then press the "New" button and insert the copied or cut elements into the new diagram, fill in the header and save - and there you go. Push the subroutine to the Arranger, get the main program back (if not already done), delete the copied elements now and replace them by the subroutine call) and let it run...
@GitMensch BTW: Your last question answered here ("What is the fastest way of moving parts of an algorithm into a new subroutine?") would be a neat proposal for the FAQ page. :wink:
@fesch Read that?
@codemanyak As you said that you wouldn't place this short "STANDARDABWEICHUNGSBERECHNUNG" part to a subroutine, don't you think it would be nice to frame this and place the comment into the frame?
Anyway I won't fix it very soon. I had really hard work with the parser stuff just now...