# Structural diagrams for processing code

**URL:** <https://discourse.processing.org/t/structural-diagrams-for-processing-code/28253>\
**Category:** Coding Questions\
**Created:** [March 4, 2021, 11:12am UTC](https://discourse.processing.org/t/structural-diagrams-for-processing-code/28253 "2021-03-04T11:12:40Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![kalle](https://avatars.discourse-cdn.com/v4/letter/k/aeb1de/32.png) [@kalle](https://discourse.processing.org/u/kalle)\
**Post date:** [March 4, 2021, 11:12am UTC](https://discourse.processing.org/t/structural-diagrams-for-processing-code/28253/1 "2021-03-04T11:12:40Z")

</div>

Processing is now an interesting alternative to other programming languages at many universities in courses.  
As far as algorithms are concerned different graphical representations are used: UML, flow charts, structure diagrams (Nassi-Shneidermann).

> **[Nassi–Shneiderman diagram](https://en.wikipedia.org/wiki/Nassi-Shneiderman_diagram)**
>
> A Nassi–Shneiderman diagram (NSD) in computer programming is a graphical design representation for structured programming. This type of diagram was developed in 1972 by Isaac Nassi and Ben Shneiderman who were both graduate students at Stony Brook University. These diagrams are also called structograms, as they show a program's structures.
> Following a top-down design, the problem at hand is reduced into smaller and smaller subproblems, until only simple statements and control flow constructs rem...

When it comes to imperative programming, flow charts are certainly “out of date”:  
"Goto considered harmful ! " (see the lecture of Dijskstra68)

It may be due to the consistent graph-theory-based diagram paradigm of UML that they nevertheless became the blueprint for activity diagrams, which may be lamented. Their original advantage easily to be sketched on a sheet of paper, where space problems could be circumvented by “spaghetti drawing”, had long turned into a clear disadvantange, particularly regarding the efforts in computer-based design. (To derive structured code from a “wild” flowchart is anything but trivial.)  
Structure diagrams offer a good alternative for graphically representing code parts that are not so extensive.  
There is an interesting tool called “Structorizer” (open source, several developers).  
[https://structorizer.fisch.lu](https://structorizer.fisch.lu)  
What I find interesting is that recently this tool can import PROCESSING code  
and display it as a structure diagram. Export to Latex also works.  
This may be very practical for scientific publications or in courses where algorithms are to be presented in a rather language-independent way. (It might be mentioned here that the diagram export to several programming languages is also supported: An export as Java code could easily be tweaked to a PROCESSING source.)