S T R U C T O R I Z E R - User Guide
Preferences > Analyser

The Analyser Preferences Dialog

The Analyser Preferences dialog is opened by means of the Preferences menu:

Preferences menu with Analyser preferences selected

The Analyser is an advanced feature, which analyses the structogram in real-time against different rules that structograms should comply with and checks it for obvious inconsistencies (like loops where the body has no impact on the condition and hence may unwillingly form an eternal loop).

Since version 3.25-07, the configurable Analyser rules are presented in a multi-tab dialog. It roughly categorizes the rules into (1) essential algorithmic tests and (2) checks concerning identifier naming and code style conventions. Version 3.27_02 added a tab with (3) hints and tutoring (see Guided Tours / Tutoring):

Analyser settings tab 1 (algorithmic issues)

Among the convention rules there are also several ones that have been specially designed for Luxemburgish students. In Luxemburgish schools these rules are mandatory. The most special ones of this kind are marked with "(LUX/MEN)". So you may opt them out if you haven't to obey these rules.

Analyser settings (naming and convention tab)

Actually, each rule can be enabled or disabled independently. The analyser itself can be activated or disabled as a whole via the "Diagram" menu (see Settings > Analyse structogram?) or by pressing the <F3> key.

The analyser strongly relies on the Parser Preferences. If, syntactically seen, you don't stick very close to them, the analyser will not work correctly but probably produce a lot of needless warnings.

Note: As it is proven that a program can never absolutely predict the behaviour of another program, the messages produced by the analyser should at best be considered as hints. They might be misleading or even wrong in certain cases!

The third tab is dedicated to some smoothly guided tours, two prototypes of which are available with version 3.27-02. Further ones are likely to be added:

Analyser Preferences with tab hints/tutoring

Rule Type Explanation

(Checkbox order may change, this list follows the one presented by version 3.25-07, see screenshots above.)

Instructions

  • Check for non-initialized variables.
    See Analyser for examples. This check reports all names occurring in expressions and adhering to strict identifier syntax (see "Ceck for valid identifiers" below), which have not been initialized in a preceding instruction. This includes all names for which there is no initialisation at all. This means if a variable was used prior to its first assignment. Varisables initialized only in some branches of an alternative or CASE statement are also reported as potentially uninitialized.
  • Check for assignment errors.
    This analysis detects instruction lines containing an equality comparison operator but no assignment operator. Since in many languages (including C, Java, PHP, etc.) the single equality sign '=' is used as assignment operator, unfortunately, one easily writes it here as well, instead of := or <-, so the check will warn in such cases. The check doesn't make sense, therefore, if you willingly fill in source code complying with the syntax of such a programming language (see No conversion of the expression/instruction contents in Export Options, by the way) and aren't interested in language-independent executability.
  • Check for possible violations of constants.
    If enabled, Analyser will complain on any attempt to redefine or modify the value of a defined constant. Examples:
    Example 1 for check 22  demo for constant checks with records
  • Check type definitions.
    This analysis checks e.g. whether type definitions are syntactically incorrect or duplicate or contradicting or if variables don't adhere to their defined structure or e.g. aren't declared but used as records (chiefly in case of record variables):
    Three analyser messages because of record type violations

Conditions and Alternatives

  • Check for assignment in conditions
    Though legal in languages like C, a condition test shouldn't have side-effects in structured programming, in particular, there should not be an assignment operator in conditions of loops, alternatives or CASE statements. (Executor would handle it as an error, anyway.) The legality of assignments in C conditions is a common source for bugs (accidently an assignment operator = is used instead of the intended == comparison operator). Note that Executor does not allow to execute a call to another subroutine diagram in a condition (which would also raise the risk of a clandestine value change).
  • Check for incorrect use of the IF-statement
    If only one branch of an alternative is needed then the "TRUE" branch (i.e. the left branch) is to be used. (This is quite easy to achieve by negating the condition if necessary.) Analyser reports If statements where the "TRUE" branch is empty no matter if the "FALSE" branch contains instructions.

Loops

  • Check for modified loop variable
    The manipulation of the counter variable of a For loop by the loop body is regarded as a no-go (though often seen in C or Java code), some programming languages (like Pascal) do explicitly prohibit this interference with the loop control mechanism. Moreover, syntax errors like too few (i.e. none) or too many counter variables in the loop header are reported if this option is chosen.
  • Check for consistency of FOR loop parameters.
    A For loop is a conveniently combined loop, which may adhere to one of two different types (counting loop / traversing loop). A dedicated editing support for the header is provided (see there), resulting in some possible redundancy between the specific entry fields and the full text. Whereas the element editor tries to synchronize the information according to the detected type, loading a diagram that had been created under different pereference settings may not fit into the consistency requirements. This Analyser check detects logical differences or even conflicts among the representations. In case of a counting loop it further generates a warning if step value is configured not beeing a legal no-zero integer constant. It also detects if a variable name collides with a configured FOR loop parser keyword.
  • Check for endless loop (as far as detectable!)
    Unlike intentionally inserted endless loops, an algorithm must be able to leave a loop eventually. While a For loop has a counting mechanism where the loop body should not interfere, an impact of the loop body on the loop condition of While and Repeat loops is necessary. Hence, if the loop body does not change the value of any of the variables refered to by the loop condition, the Analyser will assume that the algorithm probably fails to get out of the loop.

Functions/Procedures and Calls

  • Check that a subroutine header has a parameter list.
    Subroutines (functions / procedures) do some subordinate work within a program. Some subroutines just execute a fixed algorithm without alteration, but usually subroutine calls apply an algorithm to different sets of appropriate data (e.g. in order to compute the medium value of some array of numbers) where these data (e.g. the respective array) are to be passed to the subroutine as parameters. The list of parameter names is expected to be enclosed by parentheses and immediately to follow the subroutine name. This check ensures that such a parenthesized parameter list is present. It may be empty (if the subroutine doesn't need arguments), but at least the parentheses should be there. A main program header, however, may come without parameter list. So this check only applies to subroutine diagrams. (Structorizer may tolerate a subroutine diagram with missing parameter list and handle it as if it had an empty parameter list, but programming languages might regard a missing parameter list as syntax error.)
  • Check if, in case of a function, it returns a result.
    A diagram of subroutine type will often represent a function, i.e. a mapping of input data to result data, the latter of which are to be returned to the calling program level. If this check is enabled then it analyses whether or not the routine will provide such a result value in any case (i.e. no matter which path through the algorithm is taken). Be aware that Structorizer supports several ways to provide a result value:
    • by using a return instruction,
    • by assigning the value to a variable named "result" or "RESULT",
    • by assigning the value to a variable named after the routine.
    Therefore it is also checked if the function happens to employ more than one of these three mechanisms, which causes ambiguity.
  • Check for inappropriate subroutine CALLs and missing call targets.
    The content of a CALL element should either be a bare external procedure call or a simple assignment instruction with a bare external function call as expression. The procedure or function name must be followed by an argument list, which is - similar to the parameter list in a subroutine header - to be enclosed between parentheses (but may be empty). The analysis here checks whether some of these restrictions are violated. Neither Executor nor code export would accept a CALL that doesn't stick to the prescribed syntax.
    Since version 3.25-03 Analyser also checks whether the called subroutine is currently available.

Jumps and Parallel Sections

  • Check for incorrect JUMP element usage
    Any of the following issues are reported:
    • JUMP elements, which are neither empty nor start with "leave", "return", or "exit" keyword (or what's configured for them);
    • Return instructions that are situated neither at diagram end nor in a JUMP element;
    • Instructions starting with an "exit" or "leave" ("break") keyword outside of a JUMP element;
    • Leave/break instructions outside a loop or specifying more levels to leave than being nested in;
    • Return instructions in a branch of a PARALLEL section;
    • Exit or leave instructions with illegal parameters (only integer constants are allowed);
    • Instructions directly following a JUMP element of arbitrary type (unreachable).
  • Check for inconsistency risks in PARALLEL sections
    If a variable being subject to modification in one of the threads of a PARALLEL section is also used in concurrent threads of the same PARALLEL section then this is reported as a potential hazard.

Identifiers and Naming Conventions

  • Check for valid identifiers.
    Induces a warning if a character sequence introduced as variable or routine name does not adhere to strict identifier syntax: only consisting of ASCII letters (of the English alphabet), digits, and underscores, not starting with a digit. See below for even more restrictive naming conventions.
  • Check that the program / sub name is not equal to any other identifier.
    Interestingly, in languages like Pascal a value assignment to a variable named after the subroutine itself is the official way to prepare the value return (and Structorizer supports this behaviour, too). If recursion is allowed (which should be in high-level languages), it must of course be possible to refer to the same name within a function call. In other contexts, however, the occurrence of the program / subroutine name in some expressions may be a sign of a potential bug. That's where this option makes sense.
  • Check that identifiers don't differ only by upper/lower case.
    Many programming languages (like C, Java, Oberon etc.) dinstinguish upper-case and lower-case letters in identifiers of variables, procedures etc. So does the Executor. Other languages (like Pascal) don't. To use names like bad, Bad, BAD, bAd, baD etc. in the same diagram is therefore not only bad style but also a limiting factor for the range of export languages, because names meant to be synonyms might be distinguished or - other way round - names thought of being distinct could be regarded as identical - both corrupting the algorithm. This check, being activated, will report every introduction of a new variable that only differs in letter case from others, previously assigned ones.
  • Checks if an identifier might collide with reserved words.
    Most programming languages use a set of reserved words - designating algorithm structures, data structures, or primitive data types. If you name a variable like one of these reserved words then the result of a code export to the respective language will cause trouble. Based on lists of important reserved words of all programming languages a code generator is plugged in for, this check will point out all instructions introducing a variable name with potential keyword collisions (and will list the languages known to use this name as reserved word).
  • Discourage use of mistakable variable names «I», «l», and «O»
    Letters "I" (upper-case i) and "l" (lower-case L) are very hard to distinguish in many fonts, moreover they may resemble the digit 1 in other fonts. The same holds for letter "O" (upper-case o), which is easily mistakable with the number 0. Is it already questionable to use single-letter identifiers at all (except within limited scope or for well-accepted concepts like coordinate names x or y), then the use of one-letter names "I", "l", and "O" as variable identifiers is a really bad idea (an absolute no-go, actually). With this check enabled, the analyser will express a respective warning wherever one of these three error-prone variable identifiers is introduced.
  • Check for UPPERCASE variable names. (LUX/MEN)
    In Luxembourg, the Ministry of Education prescribed that at public schools variable names be written in UPPERCASE. (Elsewhere this may not be a wanted code style demand.)
  • Check for UPPERCASE program / sub name. (LUX/MEN)
    In Luxembourg, the Ministry of Education prescribed that at public schools program and subroutine names be written in UPPERCASE. (Elsewhere this may not be a wanted code style demand.)
  • Check for standardized parameter name. (LUX/MEN)
    In Luxembourg, the Ministry of Education prescribed that at public schools parameter names be not only written in UPPERCASE have to be prefixed by a lower-case 'p' letter, such that "pSOMETHING" would be a legal parameter name whereas "SOMETHING" wouldn't. (Elsewhere this may not be a wanted code style demand.)
  • Check for mixed-type multiple-line instructions.
    Structorizer copes with Instruction elements that contain several lines. However, if you regard an Instruction element that contains both input and output statements or one of them together with assignments as violation of NSD principles, then this check will find such unwanted elements.
    By the way, you may easily convert a multi-line Instruction element into a sequence of single-line Instruction elements by means of the Transmutation button Wand button.

Guided Tours / Tutoring

Rather than introducing some dedicated assistants or dialogs, the guided tours just steer you smoothly via recommending hints in the Analyser report list. Ideally you start with an empty diagram (<Ctrl><N>). Then you will see some messages in the lower pane, one of them is a note informing you that a guide is switched on and how to switch it off:

Guided tour hello world step 3

  • Short "Hello World" tour.
    Guides through the creation and use of a "hello world" program.
    guided tour hello world step 1

    guided tour hello world step 2

    guided tour hello world step 3

    guided tour hello world step 4

    guided tour hello world step 5

    guided tour hello world step 6
  • Guide to first program instructions (IPO model).
    Like the Short "Hello World" tour, the insertion of an input instruction, an output instruction, and a processing instruction between them is recommended, but it already offers more freedom of choice. (Btw. IPO means "Input - Processing - Output", a fundamental and traditional division of a program into the three phases of data acquision, data processing, and data output. Even with modern interactive applications, it makes sense to separate dialog and processing. Control processes, e.g. in automation and embedded systems, mostly also adhere to this model, often within an eternal loop: measurements / sensor monitoring, control decisions, control action.)
    guided tour IPO step 2
    etc.