Danke an Euch alle.
Das hilft mir schon mal weiter.
@jaenicke
Ich habe das Beispiel gleich mal durchlaufen lassen.
Also die Standardfälle passen schon ganz gut. Nur der gesamte Else-Block wird noch nicht korrekt eingerückt. Das werde ich aber heute noch lösen können.
Das ist eben auch wieder so ein spachlicher Sonderfall. Else zum if ist etwas anders zu händeln als else zum case.
Ich konvertiere die Schlüsselwörter in Klassen mit bestimmten Eigenschaften. Bei Else im Kontext von Case werde ich wohl nur die Eigenschaft für die Einrückungsvorgaben ändern müssen.
Schaue ich mir heute Abend an.
Vor allem weiß ich natürlich auch nicht, welche Formatierungen (Einrückungen, mit oder ohne Umbrüche) da so im Umlauf sind und auf welche "Überraschungen" sich das Tool einstellen muss.
Das sollte dem Parser ja egal sein wie es
vorher war.
Hier meinte ich eher die Wünsche und Anforderungen, welche Varianten unterstützt werden müssen.
Hier muss ich immer abwägen, was beibehalten werden muss und was einfach "korrigiert" werden kann.
Z.B. Kann ein Zeilenumbruch innerhalb der Parameter einer Prozedur ausdrücklich gewünscht sein oder es kann sinnvoll sein, einen solchen automatisch zu entfernen, um die Parameter in einer Zeile zu haben. Solche Fragen stellen sich viele.
Deswegen maskiert der Optimizer weiche (automatische) Umbrüche mit einem ESCAPE (das Kästchen am rechten Rand). So weiß er, dass dieser Umbruch auf jeden Fall entfernt werden kann.
Je nach Entscheidung können in beiden Fällen (Umbruch belassen oder entfernen) potenzielle Nutzer das Tool genau deswegen ablehnen.
Ich werde also viele Optionen anbieten müssen, allerdings wären weniger Optionen grundsätzlich natürlich wünschenswert.