From the "Preferences" menu you can open the "Export Options" dialog where general or target-language-specific preferences for the code export may be configured:

What do the options mean:

• Character Set
  You may control what character encoding to use on export. Usually one of ISO-8859-1 or UTF-8 would be most appropriate (at least in western or central Europe). While "List all?" isn't checked, the choice list will only offer you about six of the most common character sets. By enabling "List all?", in contrast, you will be offered several dozens of encodings, i.e. all your Java version will know of.

• Favorite Code Export
  If you often export code to a favourite programming language, then it may appear too cumbersome always to click through the menu "File › Export › Code › Java" (for example). There is a configurable short-hand for a preferred or frequently needed target language. It is present directly in the File menu and via accelerator key <Ctrl><Shift><X>:
  
  With export option Favorite Code Export you can select the target code for that menu entry and accelerator key.
  Since version 3.29-03, there is a configurable count value next to the combobox for the favourite target language: It defines the number of consecutive successful exports to one and the same other target language after which a proposal to adopt this target langage as new favourite language is made:
  
  If you confirm ("Yes" button) then this will have the same effect as if you had chosen the new Favorite Code Export here in the Export option dialog. As soon as you export once to a different language or switch the favourite language, the counting starts again from 1.
  You may disable this proposal mechanism by decreasing the number in the spinner to 0 (also see the spinner tooltip).
  Since release 3.30, you can also alter the favourite code export language simply via the context menu (popup menu) of the Code Preview.

• No conversion of the expression/instruction contents (for all target languages)
  Though Nassi-Shneiderman diagrams are basicly syntax-free and rather rely on structure, some Structorizer features like Executor and Analyser accept and work with a (somewhat eclectic) HLL syntax, aspects of which are described on the Syntax page. Consequently, code generators also derive the target code under the assumption that instructions and expressions are written in that executable and analysable Structorizer dialect.
  This causes of course trouble if the text contents of the diagram elements have already been formulated according to the specific syntactical conventions of the intended target language. In this case, Structorizer would spoil the readily prepared text on export, trying to convert it again under false assumptions.
  So if you work and document explicitly for one favourite language and used to fill in the element texts already adhering to the specific target language syntax then you may activate this checkbox, causing only the structural (and closely related) conversions but no (or only minimum) translation of the instruction lines, conditions etc. It is a kind of "raw export", particularly valuable for dedicated shell script development (because shell syntax is practically incompatible with HLL syntax conventions).

• Export instructions as comments (relevant for most target formats):
  If this option is enabled then the code of Instruction, CALL, and EXIT elements will be exported as mere comments. (Otherwise a conversion or translation to the respective target language will be tried unless option "No conversion of the expression/instruction contents" is activated, see above).

• Put block-opening brace on same line (relevant for C, C++, C#, and Java):
  This option is related to the code style of compound instructions in C-like languages. If the option is activated then blocks will start (i.e. the position of the opening brace) at the end of the commanding line, e.g.
  if (c == 0) {
      a = 17;
  }
  Otherwise, the blocks will start at the beginning of the next line (indentation rules preserved, of course):
  if (c == 0)
  {
      a = 17;
  }

• Involve called subroutines:
  If this mode is active and your diagram to be exported contains CALL elements then the code generator looks for available matching diagrams (in the Arranger) and includes their code into the export. This way, if all required subroutine diagrams are found, the generated code will contain all necessary routine definitions to get the code runnning (after the usual manual post-processing). THe same applies for Includable diagrams referenced by the Include List of the exported diagram.
  This option applies to all languages offered for export. The subroutine dependencies are analysed and a topological sorting is attempted, i.e. the code of a subroutine precedes that of its caller. Most compilers require this order. (Be aware, though, that the resulting code for e.g. BASIC with also switched-on line numbering may be dysfunctional because the numbered lines do not easily allow the insertion of larger bunches of code from a different place).
  For group export (versions ≥ 3.30-07) the meaning is slightly different: If enabled then subroutines or Includables (see diagram type) from other groups may also be involved if referenced and not available within the same group. Otherwise their code will be missing in the exported file (you will get a warning that is listing the missing diagrams, though).

• Export author and license attributes
  If this mode is active (the default) then metainfo introduced with version 3.26-06 (name of the creator and last modifier of the diagram as well as the corresponding dates, license name and text as configurable with the Saving preferences) are also written as comments into the exported code. Otherwise they will not.

• Propose export directory from NSD location if available (since version 3.30-07)
  If this option is chosen (the default) and the diagram to be exported is associated to an .nsd file (because having been saved to or loaded from) then the file chooser dialog for the export will offer the directory of the nsd file as target folder. If the option is disabled then the file chooser dialog will always suggest you the previously used export folder. You may always choose a differing folder, of course, but it canb be really annoying if you have always to navigate to a different folder than the one proposed to you. So you have some control over the proposal policy. Both policies make sense under certain circumstances. Choose the mode that suits you most.

• Default array size (if required) (since version 3.30-08)
  Many programming languages require arrays to be declared with certain size, i.e. maximum element number. Structorizer does not so. Hence the code generators for languages with mandatory declaration will not often find enough information in the diagram to guess a sensibel size. With this option enabled, the generator will use the value specified via the spinner as default array size in such cases. (With disabled default array size, the generator might insert "???" as size or produce an otherwise defective declaration. Sometimes this is better as it signals the need for manual resolution.)

• Default string length (if required) (since version 3.30-08)
  Some languages (like C or Pascal) require string variables to be dimensioned with certain length. With this option enabled, the value specified via the spinner will be used as default length for string decarations where needed. If you prefer to resolve the declaration defects in the code manually, leave the option disabled.

• Language-specific options (for code export)
  Version 3.31-04 added a new generator plugin allowing to export diagrams as pseudocode algorithms for L^AT_EX. Initially, four different L^AT_EX packages were supported. Hence, plugin-specific export options had to be enabled. On this occasion, the line numbering option, albeit related to BASIC export, having been placed among the general export options until version 3.31-03, was now moved to a BASIC-specific subdialog. Version 3.32-02 introduced a prototype of an ARM generator, which also brings a specific export option. Here the meaning and effect of plugin-specific options is explained:

  • BASIC
    
    

    • Generate line numbers on export:
      BASIC (Beginners' All-purpose Symbolic Instruction Code) has developed numerous dialects from the very beginning. There are worlds between the first versions (about 1970ies) and some modern derivates with object-oriented enhancements etc. that hardly remind "good" old BASIC at all (Microsoft VisualBasic may serve as an extremely drifted-away example).
      So it's nearly impossible to refer to BASIC as a specific language. Correspondingly, a code export to "BASIC" is somehow a joke. We try it nevertheless.
      The option here partitions the BASIC world roughly into

      1. the ancient types with mandatory line numbers and very restricted subroutine support ("vintage" BASIC), e.g.
         10 REM This is an example of early BASIC
         20 LET C = 5
         30 ...
         
      2. and some more up-to-date style without line numbers, but with some generalised variable declarations via "dim ... as ..." etc., e.g.
         Rem This may serve as an example for modern dialects
         dim C as Integer
         C = 5
         ...
         
         
  • Perl
    
    

    • Export constants via pragma use constant (since version 3.32-20):
      By default, constant definitions will simply be exported as if they were normal variables, i.e. without write protection, and the name would be prefixed according to the Perl syntax rules for variables throughout the code. An instruction
      const PI ← 4 * atan(1)
      would therefore simply produce a code line
      $PI = 4*atan(1);.
      If you activate the above option, however, the generator would instead insert the following code line, which employs the pragma "use constant", close to the beginning of the generated file:
      use constant PI => 4 * atan(1);
      In this case, the constant name would not be prefixed in the subsequent expressions of the code.
      The option may cause inconsistencies in the code, though, since "use constant" works only if the constant value can be computed at compile time by Perl and there is no sufficient information for the code generator to decide whether this may be the case for certain expressions. The code generator guarantees at least that the "use constant" pragma is not applied to routine arguments declared as constants and constant targets of function CALLs.

  • ARM
    
    

    • Code for GNU compiler (instead of KEIL):
      By default, ARM code will be generated using the KEIL assembler language. By checking this option, GNU assembler syntax will be used for the export instead. GNU code does not only differ in the directives but even supports more features, e.g. output instructions, and can be used for embedded code in a gcc project (or for simulation in tools like CPUlator). Information about the syntax differences may be obtained here.

    • Ensure memory alignment of data and code (since version 3.32-03):
      With this option activated, .align directives will be inserted before array allocations and the text section in order to ensure that the data object or code starts at an entire word address (or properly aligned according to the size of the array elements). This option has only effect in GNU mode where the allocation directives .byte, .hword, .word, .quad, and .octa do not automatically align the address (whereas KEIL directives DCW, DCD, and DCQ do align).

    • Store strings with 0-termination (since version 3.32-04):
      Usually string literals will be stored as arrays of only the contained character code points without an additional terminating '\0' character (as in C strings). With this option enabled, however, the ARM generator will append a terminating 0 code on allocating strings.

    • Restrict to element content on ARM level (since version 3.32-05):
      Though ARM generator may evolutionarily be made capable to compile more complex expressions and instructions than with the first prototype, in certain use cases (see section Special Syntax for ARM) it may be more desirable to restrict users (e.g. students) to instruction content that is compatible with the low-level capabilities of ARM processors (e.g. to reject expressions that contain more than one operator or more than one literal). This option is intended to force algorithm design on conceptional machine level and might be made predominant if desired. (Also see plugin-specific syntax checks in Analyser Preferences.)

  • L^AT_EX/Algorithm
    
    

    • LaTeX package to be used
      Here you can choose among the following L^AT_EX packages for pseudocode algorithms which represent the algorithm in different styles and with different flexibility and built-in instruction set (e.g. some of them do not support CASE structures such that Structorizer has to decompose them into IF-ELSEIF chains). The different different L^AT_EX output shown below for the four package exports of following diagram (in all cases line numbering was set to 5 and semicolons were switched off) give you an idea of the different styles:
      

      • algorithmicx (environment variant algpseudocode):
        
      • algorithmic (aka "algorithms"):
        
      • algorithm2e:
        
      • pseudocode:
        
        (Please note that package pseudocode is incapable of breaking long lines, see e.g. the condition of the first alternative, cf. algorithmic.)

    • Line numbering step
      Some of the L^AT_EX algorithm packages allow an automatic numbering of the instruction lines, though with different comfort. Generally, value 0 will switch line numbering off. Any value > 0 switches line numbering on. Package pseudocode, however, does not support automatic line numbering in any way. For packages algorithmic and algorithmicx a value n (e.g. 5 or 10) means that only every nth line number will be shown, where all complete lines (including comments) do count. Package algorithm2e, in contrast, numbers all lines except comment lines if n > 0 (with no regard to the exact value of n). The examples above (i.e. for option "LaTeX package to be used") illustrate very well the different effect of value 5.

    • Put a semicolon after every instruction
      With this option unchecked, the instruction lines will not end with a semicolon (like in Structorizer). Check this option to append a semicolon to all instructions.

The Includes tab on the export options dialog allows to configure lists of files or modules formally to be included (or imported) by the exported code, i.e. on exporting a diagram to source code, the code generator will insert include directives, import or use declarations if there are some configured entries in the text field for the respective target language here:

• For a certain target language, fill in a comma-separated list of entities to be placed in include/import/use directives. What the entities mean and how the respective directive will look like depends on the target language. This configuration opportunity is thought for the case that you might produce a large number of diagram exports to a specific target language where always certain user-specifc file includes, module imports etc. would otherwise have to be inserted manually for each of them. The example above shows a version requirement for Perl that would look like
  use 5.6.1;
  in the produced code, whereas on C export you would obtain the two following lines near the top of the file (similar with C++):
  #include <stddef.h>
#include "mumpitz.h"
  On export to Java, the file would be forced to contain a line
  import javax.swing.*;
  (The generators are usually not capable of producing different kinds of directives for a single language — one might want to have both #include and using directives for C++, but the latter isn't supported.)
  Note that in batch export mode you will have to specify a settings file containing them in order to achieve them being considered.

Further options may be added on user demand.

Note: Since version 3.30-11, all GUI-commanded code export features can be suppressed (i.e. they will vanish from the menus) via a line "noExportImport=1" in a central predominant ini file. This preference line can only manually be put into such a file (e.g. by means of a text editor).