Analyser

Der Analyser-Präferenzen-Dialog wird über das Menü „Preferences" (Präferenzen) geöffnet. Der Analyser ist eine erweiterte Funktion, die das Struktogramm beständig auf verschiedene Regeln hin analysiert, die Struktogramme einhalten sollten, und es auf offensichtliche Inkonsistenzen überprüft (z. B. Schleifen, deren Rumpf keine Auswirkung auf die Bedingung hat und daher möglicherweise unbeabsichtigt eine Endlosschleife bildet).

Die für die Konfiguration verfügbaren Analyser-Regeln werden in einem Multi-Tab-Dialog präsentiert. Er kategorisiert die Regeln grob in:

1. wesentliche algorithmische Tests,
2. allgemeine Syntaxprüfungen (seit Version 3.32-01),
3. Prüfungen bezüglich Bezeichnerbenennungen und Code-Stil-Konventionen, sowie
4. Hinweise und Betreuung (siehe Geführte Touren / Betreuung):

Seit Version 3.30-14 werden Elemente, die mit einer oder mehreren Warnungen im Analyser-Bericht zusammenhängen, standardmäßig mit einem kleinen roten Dreieck in der oberen linken Ecke markiert (siehe Beispiel-Screenshots weiter unten), um die Aufmerksamkeit des Benutzers auf die Warnungen in der Berichtsliste zu lenken. Die Einführung dieser Funktion wurde von einem neuen Kontrollkästchen am unteren Rand des Analyser-Präferenzen-Dialogs begleitet: „Draw warning sign in affected elements" (Warnsymbol in betroffenen Elementen zeichnen). Durch Deaktivieren dieses Kontrollkästchens kann diese Anzeige abgeschaltet werden. (Sie wird natürlich auch durch Deaktivieren des Analysers unterdrückt.)

Unter den Konventionsregeln befinden sich auch einige, die speziell für luxemburgische Schüler konzipiert wurden. In luxemburgischen Schulen sind diese Regeln vorgeschrieben. Die speziellsten dieser Art sind mit „(LUX/MEN)" gekennzeichnet. Sie können diese also abwählen, wenn Sie diese Regeln nicht einhalten müssen.

Jede Regel kann unabhängig aktiviert oder deaktiviert werden. Der Analyser selbst kann als Ganzes über das Menü „View" (siehe Settings > Analyse structogram?) oder durch Drücken der Taste <F3> aktiviert oder deaktiviert werden.

Der Analyser stützt sich stark auf die Parser-Präferenzen. Wenn Sie sich syntaktisch nicht sehr eng an diese halten, funktioniert der Analyser nicht korrekt und erzeugt wahrscheinlich viele unnötige Warnungen.

Hinweis: Da es erwiesen ist, dass ein Programm das Verhalten eines anderen Programms niemals absolut vorhersagen kann, sollten die vom Analyser erzeugten Meldungen bestenfalls als Hinweise betrachtet werden. Sie können in bestimmten Fällen irreführend oder sogar falsch sein!

Die vierte Registerkarte ist einigen sanft geführten Touren gewidmet. Seit Version 3.27-02 sind zwei Prototypen davon verfügbar. Weitere werden wahrscheinlich hinzugefügt:

Regeltypen – Erklärung

(Die Reihenfolge der Kontrollkästchen kann sich ändern; diese Liste folgt der von Version 3.32-36 präsentierten, siehe Screenshots oben.)

Anweisungen

• Nicht initialisierte Variablen prüfen.
  Siehe Analyser für Beispiele. Diese Prüfung meldet alle Namen, die in Ausdrücken vorkommen und strikter Bezeichner-Syntax entsprechen (siehe „Check for valid identifiers" unten), die in einer vorhergehenden Anweisung nicht initialisiert wurden. Auch Variablen, die nur in einigen Zweigen einer Alternative oder CASE-Anweisung initialisiert werden, werden als potenziell nicht initialisiert gemeldet.
• Zuweisungsfehler prüfen.
  Diese Analyse erkennt Anweisungszeilen, die einen Gleichheitsvergleichsoperator, aber keinen Zuweisungsoperator enthalten. Da in vielen Sprachen (einschließlich C, Java, PHP usw.) das einfache Gleichheitszeichen '=' als Zuweisungsoperator verwendet wird, schreibt man es hier leicht statt := oder <-, daher wird in solchen Fällen gewarnt.
• Mögliche Verletzungen von Konstanten prüfen.
  Bei Aktivierung warnt der Analyser bei jedem Versuch, den Wert einer definierten Konstante neu zu definieren oder zu ändern.





• Typdefinitionen und Komponentenzugriffe prüfen.
  Diese Analyse prüft z. B., ob Typdefinitionen syntaktisch falsch, doppelt oder widersprüchlich sind, oder ob Variablen ihrer definierten Struktur nicht entsprechen.

Bedingungen und Alternativen

• Zuweisung in Bedingungen prüfen.
  Obwohl in Sprachen wie C zulässig, sollte ein Bedingungstest in der strukturierten Programmierung keine Seiteneffekte haben; insbesondere sollte kein Zuweisungsoperator in Bedingungen von Schleifen, Alternativen oder CASE-Anweisungen vorhanden sein.
• Falsche Verwendung der IF-Anweisung prüfen.
  Wenn nur ein Zweig einer IF-Anweisung benötigt wird, ist der TRUE-Zweig (d. h. der linke Zweig) zu verwenden. Der Analyser meldet IF-Anweisungen, bei denen der TRUE-Zweig leer ist, egal ob der FALSE-Zweig Anweisungen enthält.
• Prüfen, dass der CASE-Auswahlen wert kein strukturierter Typ ist (Versionen ≥ 3.30-16).
  Aktiviert Warnungen, wenn der Auswahlausdruck zweifellos einen strukturierten Typ darstellt.
• Prüfen, dass CASE-Selektorelemente ganzzahlige Konstanten sind (Versionen ≥ 3.30-02).
  Einige Ziel-Programmiersprachen akzeptieren möglicherweise nur ganzzahlige Konstanten als Selektorwerte.
• Prüfen, dass CASE-Selektorlisten disjunkt sind (Versionen ≥ 3.30-02).
  Wenn ein Selektorwert in mehreren Zweigbeschriftungen eines CASE-Elements vorkommt, wird dies als möglicher Designfehler gemeldet.

Schleifen

• Modifizierte Schleifenvariable prüfen.
  Die Manipulation der Zählervariable einer FOR-Schleife durch den Schleifenrumpf gilt als No-Go. Auch Syntaxfehler wie zu wenige oder zu viele Zählervariablen im Schleifenkopf werden gemeldet.
• Konsistenz der FOR-Schleifenparameter prüfen.
  Erkennt logische Unterschiede oder Konflikte zwischen den Darstellungen sowie weitere Inkonsistenzen.
• Endlosschleife prüfen (soweit erkennbar!).
  Wenn der Schleifenrumpf den Wert keiner der in der Schleifenbedingung referenzierten Variablen ändert, nimmt der Analyser an, dass der Algorithmus wahrscheinlich nicht aus der Schleife herauskommt.

Funktionen/Prozeduren und Aufrufe

• Prüfen, dass ein Unterprogrammkopf eine Parameterliste hat.
  Diese Prüfung stellt sicher, dass eine geklammerte Parameterliste vorhanden ist.
• Prüfen, ob ein Funktionsdiagramm ein Ergebnis zurückgibt.
  Analysiert, ob die Routine tatsächlich in jedem Fall einen Ergebniswert liefert, wenn ein Ergebnistyp angegeben ist.
• Auf unangemessene Unterprogramm-CALLs und fehlende Aufrufziele prüfen.
  Prüft, ob der Inhalt eines CALL-Elements den vorgeschriebenen Syntaxregeln entspricht und ob das aufgerufene Unterprogramm verfügbar ist.
• Gegen fehlerhafte Diagramm-Importe prüfen.
  Impliziert verschiedene Prüfungen für die korrekte Verwendung von einschließbaren Diagrammen.
• Warnung bei Verwendung pixel-rundender Turtleizer-Prozeduren «fd», «bk».
  Warnt vor dem Einsatz der weniger präzisen Turtleizer-Routinen, die Pixel runden.

Sprünge und Parallele Abschnitte

• Falsche EXIT-Element-Verwendung und nicht erreichbare Elemente prüfen.
  Meldet verschiedene Probleme rund um EXIT-Elemente, unreachable instructions sowie fehlerhafte leave/break/return-Verwendungen.
• Inkonsistenzrisiken in PARALLEL-Abschnitten prüfen.
  Wenn eine Variable, die in einem Thread eines PARALLEL-Abschnitts geändert wird, auch in parallelen Threads desselben PARALLEL-Abschnitts verwendet wird, wird dies als potenzielles Risiko gemeldet.

Allgemeine Syntax

• Prüfen, dass Klammern ausgeglichen und korrekt verschachtelt sind (Versionen ≥ 3.32-01).
  Löst eine Warnung aus, wenn öffnende und schließende Klammern nicht übereinstimmen.
• Syntax von Variablendeklarationen und Initialisierungen prüfen (Versionen ≥ 3.32-13).
  Prüft, dass Variablendeklarationen in Pascal/Basic-Stil neue Bezeichner einführen und korrekte Typangaben enthalten.



• Auf nicht unterstützte C-Operatoren wie ++, --, +=, -=, *= usw. prüfen (Versionen ≥ 3.32-36).
  Löst eine Warnung aus, wenn auto-inkrement-, auto-dekrement- oder kombinierte Zuweisungsoperatoren in Ausdrücken auftreten, die Structorizer nicht unterstützt.
• Einhaltung ARM-spezifischer Syntaxkonventionen prüfen (Versionen ≥ 3.32-05).
  Erzwingt eine sehr strenge Grammatikprüfung für alle Elemente, die mit dem ARM-Code-Generator zusammenhängt.

Bezeichner und Namenskonventionen

• Auf gültige Bezeichner prüfen.
  Löst eine Warnung aus, wenn ein Zeichenfolge als Variablen- oder Routinenname nicht der strikten Bezeichner-Syntax entspricht.
• Prüfen, dass der Programm-/Unterprogrammname keinem anderen Bezeichner entspricht.
  Erkennt das Auftreten des Programm-/Unterprogrammnamens in Ausdrücken, was ein Hinweis auf einen potenziellen Fehler sein kann.
• Prüfen, dass Bezeichner sich nicht nur durch Groß-/Kleinschreibung unterscheiden.
  Meldet jeden neuen Variableneinführung, die sich von bereits zugewiesenen nur durch Buchstabengroßschreibung unterscheidet.
• Prüfen, ob ein Bezeichner mit reservierten Wörtern kollidieren könnte.
  Weist auf Variablennamen hin, die in bestimmten Zielsprachen als reservierte Wörter verwendet werden.
• Verwendung verwechselbarer Variablennamen «I», «l» und «O» abschrecken.
  Warnt bei der Verwendung der drei besonders fehleranfälligen einbuchstabigen Bezeichner.
• Prüfen, ob ein Bezeichner mit Diagramm-Controller-Routinen kollidieren könnte.
  Warnt, wenn ein Variablenname mit einer Routinenbezeichnung eines aktivierten Diagramm-Controller-Moduls (z. B. Turtleizer) kollidiert.
• GROSSBUCHSTABEN-Variablennamen prüfen. (LUX/MEN)
  In luxemburgischen Schulen vorgeschrieben: Variablennamen müssen in GROSSBUCHSTABEN geschrieben werden.
• GROSSBUCHSTABEN-Programm-/Unterprogrammname prüfen. (LUX/MEN)
  In luxemburgischen Schulen vorgeschrieben: Programm- und Unterprogrammnamen müssen in GROSSBUCHSTABEN geschrieben werden.
• Standardisierten Parameternamen prüfen. (LUX/MEN)
  In luxemburgischen Schulen vorgeschrieben: Parameternamen müssen mit einem kleinen 'p' vorangestellt werden, z. B. „pEINWERT".
• Auf gemischt-typisierte mehrzeilige Anweisungen prüfen.
  Meldet Anweisungselemente, die sowohl Ein- als auch Ausgabeanweisungen oder diese zusammen mit Zuweisungen enthalten.

Geführte Touren / Betreuung

Statt dedizierter Assistenten oder Dialoge führen die geführten Touren den Benutzer sanft durch empfehlende Hinweise in der Analyser-Berichtsliste. Idealerweise beginnen Sie mit einem leeren Diagramm (<Ctrl><N>). Im unteren Bereich sehen Sie dann Meldungen, darunter eine Notiz, die Sie darüber informiert, dass eine Tour aktiv ist und wie Sie diese abschalten. Ein kleines blaues Markierungsdreieck erinnert ebenfalls daran, dass Tutorial-Hinweise in der Berichtsliste vorhanden sind (ab Version 3.30-14):

• Kurze „Hello World"-Tour.
  Führt durch die Erstellung und Verwendung eines „Hello World"-Programms.
• Anleitung zu ersten Programmanweisungen (IPO-Modell).
  Wie die „Hello World"-Tour empfiehlt diese Tour das Einfügen einer Eingabeanweisung, einer Ausgabeanweisung und einer Verarbeitungsanweisung, bietet aber bereits mehr Freiheit bei der Auswahl. (IPO steht für „Input – Processing – Output", eine grundlegende und traditionelle Einteilung eines Programms in die drei Phasen Dateneingabe, Datenverarbeitung und Datenausgabe.)