UnitOptimizer

[dummzeuch]

Meine Bevorzugte Einrückung:

Delphi-Quellcode:

case bla of
  0: begin
    doSomething;
  end;
  1: begin
    doSomethingElse;
  end;
else
  DefaultCode;
end;

Auch ich verwende meist begin/end, auch wenn es nicht unbedingt notwendig ist.

Wenn ich mir eine Syntax wünschen dürfte, wäre sie:

Delphi-Quellcode:

case bla of
  0:
    doSomething;
  end;
  1:
    doSomethingElse;
  end;
else
  DefaultCode;
end;

Also ohne begin, aber das geht ja leider nicht.

[venice2]

Zitat:

Also ohne begin, aber das geht ja leider nicht.

Nein?
Klar geht das solange man nur eine Funktion -> Aufruf im case verwendet.
Dein End hat da nichts zu suchen.

Delphi-Quellcode:

case bla of
  0:
    doSomething;
  1:
    doSomethingElse;
else
  DefaultCode;
end;

[Uwe Raabe]

Für den Else-Zweig funktioniert das aber jetzt schon. Da wäre ein zusätzliches begin-end überflüssig:

Delphi-Quellcode:

  case Bedingung of
    1: begin
        Tuwas;
      end;
    2: begin
        Abwarten;
      end;
  else
    MachNix;
    MichWasAnderes;
  end;

Siehe: http://docwiki.embarcadero.com/RADSt...se-Anweisungen

Zitat:

Jeder in einer caseList angegebene Wert muss innerhalb der case-Anweisung eindeutig sein. Teilbereiche und Listen dürfen sich nicht überschneiden. Eine case-Anweisung kann über eine abschließende else-Klausel verfügen:

Delphi-Quellcode:

 case selectorExpression of
   caseList1: statement1;
    ...
   caselistn: statementn;
 else
   statements;
 end

statements ist eine Folge von Anweisungen, die durch Strichpunkte voneinander getrennt sind. Bei der Ausführung einer case-Anweisung wird höchstens eine statement1 ...statementn-Anweisung ausgeführt. Dabei handelt es sich um genau diejenige, deren caseList-Wert mit dem von selectorExpression identisch ist. Ist kein entsprechender selectorExpression-Wert in caseList vorhanden, werden die Anweisungen in der else-Klausel (falls vorhanden) ausgeführt.

[dummzeuch]

Zitat:

Zitat von venice2 (Beitrag 1476251)

Zitat:

Also ohne begin, aber das geht ja leider nicht.

Nein?
Klar geht das solange man nur eine Funktion -> Aufruf im case verwendet.
Dein End hat da nichts zu suchen.

Delphi-Quellcode:

case bla of
  0:
    doSomething;
  1:
    doSomethingElse;
else
  DefaultCode;
end;

Tja, genau das ist das Problem: Ich will ein End, aber eigentlich kein Begin.

[Uwe Raabe]

Theoretisch wäre auch das

Delphi-Quellcode:

end

nicht notwendig, da die Befehlssequenz entweder durch ein neues case-Label, das

Delphi-Quellcode:

else

oder ein

Delphi-Quellcode:

end

beendet wird. Aber das ist nun mal schon vor langer Zeit eben so festgelegt worden...

[venice2]

Zitat:

Tja, genau das ist das Problem: Ich will ein End, aber eigentlich kein Begin.

Ok!
Nur der sinn dahinter erschließt sich mir nicht.

Zitat:

Theoretisch wäre auch das end nicht notwendig

Nun. Er hätte es gern :)

[jaenicke]

Zitat:

Zitat von stahli (Beitrag 1476227)

Ich will Euch mal fragen, wie Ihr die Formatierung der Case-Anweisung sehen würdet bzw. welche Optionen Ihr dazu für wünschenswert haltet.
In der Beziehung bin ich selbst nicht ganz schlüssig.

Ich finde die Schreibweise aus dem Styleguide am übersichtlichsten (wobei ich die erste wegen 1 Befehl pro Zeile suboptimal finde und die Leerzeilen aus der zweiten überflüssig und daher die letzte präferiere):

Zitat:

Delphi-Quellcode:

  // CORRECT
  case Control.Align of
    alLeft, alNone: NewRange := Max(NewRange, Position);
    alRight: Inc(AlignMargin, Control.Width);
  end;
  

  // CORRECT
  case x of

    csStart:
      begin
        j := UpdateValue;
      end;

    csBegin: x := j;

    csTimeOut:
      begin
        j := x;
        x := UpdateValue;
      end;
      
  end;
      
  // CORRECT
  case ScrollCode of
    SB_LINEUP, SB_LINEDOWN:
      begin
        Incr := FIncrement div FLineDiv;
        FinalIncr := FIncrement mod FLineDiv;
        Count := FLineDiv;
      end;
    SB_PAGEUP, SB_PAGEDOWN:
      begin
        Incr := FPageIncrement;
        FinalIncr := Incr mod FPageDiv;
        Incr := Incr div FPageDiv;
        Count := FPageDiv;
      end;
  else
    Count := 0;
    Incr := 0;
    FinalIncr := 0;
  end;

Zitat:

Zitat von stahli (Beitrag 1476227)

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.

[himitsu]

Zeilenumbrüche, Leerzeichen und Tabs sind erstmal vollkommen egal. (eigentlich sogar alles von #1 bis ' ')
Einzige Ausnahme ist der Zeilenumbruch hinter //-Kommentaren.
Ein ; vor einem END wäre auch "optional", sowie doppelte ;; ... aber ich empfehle immer ; zu schreiben (außer vor einem ELSE bzw. nach einem THEN/DO)

Das ist ja auch der Grund, warum ein Code-Formatierer alles umformatieren und nach "belieben" Zeilenumbrüche und Einrückungen einfügen/entfernen/ändern kann. :zwinker:
(nicht so wie bei Python, wo die Einrückung essenziell ist und mit zum Programm-Code gehört)

[stahli]

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.

Zitat:

Zitat von jaenicke (Beitrag 1476260)

Zitat:

Zitat von stahli (Beitrag 1476227)

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.

[stahli]

... also das mit dem Einrücken funktioniert wie erwartet :-)


Wer mal einen kleinen Einblick möchte:

Delphi-Quellcode:

                if SupportsIn(lItemBlockStart, [IDetectThen, IDetectElse, IDetectDo]) then
                  begin
                    if Supports(lItemBlockStart, IDetectElse, lDetectElse) then
                      lDetectCaseFlag := Supports(lDetectElse.ItemBlockStartLink, IDetectCase)
                    else
                      lDetectCaseFlag := False;
                    if (lDetectCaseFlag) then
                      currentRealAlign.LeftSpaceNext := currentRealAlign.LeftSpaceNext + 1 // Sonderfall Else zum Case  --> NEU <--
                    else
                      if (not lDetectExceptFlag) then
                        currentRealAlign.IncLeftSpaceMove; // sonst nach then/else/do eine Zeile/Anweisung einrücken (wenn Zeilenende)
                  end;

Zu den Format-Sonderfällen ist jetzt ein neuer Sonderfall hinzu gekommen. ;-)
Ich versuche das halt alles durch zugewiesene Eigenschaften zu deklarieren, die der Formatierer dann entsprechend umsetzt.
Da spielen dann noch die ganzen Verschachtelungen und Blöcke hinein.