Break / Exit - Grundsatzfrage

[burn]

Hallo,

habe mal eine eine grundsätzliche Frage.

Oft genug habe ich jetzt schon in der DP gelesen, daß
die Benutzung von Break und Exit schlechter Programmier-Stil ist.

Aber wie löse ich dann z.B. folgendes Problem:

Ich habe eine Liste bzw. Array mit Strings und möchte prüfen
ob ein String schon in der Liste vorhanden ist.

Ich mach das immer so:

Delphi-Quellcode:

function InListeVorhanden(SuchString: string): Boolean;
begin
  Result := False;
  for i := 0 to List.Count-1 do
  begin
    if SuchString = List[i] then 
    begin
     Result := True;
     Exit;
    end;
  end;
end;

Setze ich ja hier das Exit nicht, rattert die Funktion ja durch die ganze Liste was
ja durchaus langsamer kein kann, wenn der Suchstring beim Index 5 gefunden
wird und z.B. 10000 Einträge vorhanden sind.

Wie sollte man es sonst machen, wenn man "guten" Programmier-Stil verwenden will.

MfG Burn...

[taaktaak]

Moin, Moin.
Nun, wenn die Liste unsortiert ist, mache ich es auch so - und habe kein schlechtes Gewissen! In einer sortierten Liste wäre das natürlich eine schlechte Lösung. Da kommt man ja durch binäre Suche viel eleganter zum Ziel.

[mirage228]

Du kannst das aber auch mit einer while...do schleifen lösen - gänzlich ohne Break und Exit :)

Edit: TStringList.IndexOf macht auch genau das was du willst, aber es ist wenn ich mich recht erinnere so ziemlich genauso umgesetzt wie du es jetzt hattest... ;)

[DeddyH]

Erstmal: exit verlässt die komplette Methode, break nur die aktuelle Schleife. Und beide kann man durch eine zusätzliche Schleifenbedingung umgehen, wobei das bei einer for-Schleife nicht gehen kann, hier muss man dann auf while ausweichen.

Delphi-Quellcode:

function InListeVorhanden(SuchString: string): Boolean;
var i: integer;
begin
  Result := False;
  for i := 0 to List.Count-1 do
  begin
    if SuchString = List[i] then
    begin
     Result := True;
     break;
    end;
  end;
end;

function InListeVorhanden(SuchString: string): Boolean;
var i: integer;
begin
  Result := False;
  i := 0;
  while (i < List.Count) and not Result do
  begin
    if SuchString = List[i] then
      Result := True;
    inc(i); 
  end;
end;

@Ralph: darum geht es ja nicht ;)

[taaktaak]

Sind for-Schleifen nicht schneller als while-Schleifen?

[quendolineDD]

Nehm eine while-Schleife und setz das, worauf du prüfst als Bedingung

Delphi-Quellcode:

begin
result := False;
i := 0;
while (not Result) and (i < (List.Count -1)) do
begin
 inc(i);
 Result := (Suchstring = List [i]);
end;
end;

[Sherlock]

Delphi-Quellcode:

function InListeVorhanden(SuchString: string): Boolean;
var i: integer;
begin
  Result := False;
  i:= 0;
  repeat
    if SuchString = List[i] then 
      Result := True;
    inc(i);
  until Result or (i = (List.Count-1));
end;

Ganz ohne Exit ;)

Oh...Roter Kasten ist wohl beim Weihnachtsmann aufm Schlitten.

Sherlock

[DeddyH]

Sherlock, bei einer leeren Liste bekommst Du mit einer Fußschleife aber Kummer.

[mirage228]

Zitat:

Zitat von taaktaak

Sind for-Schleifen nicht schneller als while-Schleifen?

Bei einer for-Schleife wird meines Wissens nach der Wert für den Zähler nur einmal abgerufen, bei "while" bei jedem Durchlauf - in wie fern die Compiler-Optimierung die while-Schleife rückwärts laufen lässt, wie sie es in bestimmten Fällen bei der for-Schleife tut, weiß ich aber nicht...

Im Zweifelsfall die beiden Methoden mal über GetTickCount() vergleichen =)

[ATSV]

wenn ihr so weitermacht haben wir wieder das selbe wie mit der negativen zahl :lol:

[taaktaak]

Und das war doch sehr amüsant...

[Sherlock]

Zitat:

Zitat von DeddyH

Sherlock, bei einer leeren Liste bekommst Du mit einer Fußschleife aber Kummer.

Stimmt auffallend.

Muss man halt noch ne Prüfung reinsetzen, aber es ging ja um den Grundgedanken, ohne Exit auskommen zu können (hat mich das jetzt gerettet? 8) )

Sherlock

[DeddyH]

Zitat:

Zitat von Sherlock

hat mich das jetzt gerettet?

Nur, weil Weihnachten für der Tür steht :-D

[burn]

Ok, Ok .. überredet !!! :oops: ..

Es geht auch mit "gutem" Stil (while Schleife) ...

Bevor ich jetzt wieder einen Thread ala "Negative Zahl errechnen" zu
verantworten habe, sag ich Danke für den Tip.

Aber was ist daran so verwerflich Exit und Break zu benutzen.
Für was gibt es die, wenn man diese nicht benutzen soll.

Ich z.B. Finde so was besser

Delphi-Quellcode:

  if Liste.Count = 0 then 
    Exit
  
  weitere 40 Zeilen Code

als

Delphi-Quellcode:

  if Liste.Count > 0 then
  begin
    .
    .
    .
    weitere 40 Zeilen
    .
    .
    .
  end;

mfg Burn

[guidok]

Ich bin jetzt kein Verfechter von Exit oder Break, allerdings verwende ich es auch bedenkenlos, wenn ich es für angebracht halte, deshalb:

Inwiefern ist Exit/Break schlechter Programmierstil?

Welche Nachteile erwachsen mir dadurch?

[himitsu]

For- und While-"Schleifchen" sind intern eigentlich gleich.
Bei den Repeat-Until-"Schleifchen" wird nur der Ausdruck zuletzt ausgewertet

Delphi-Quellcode:

for i := i2 to i3 do begin

  if xyz then break;

end;

// entspricht (bzw)

i := i2;
while i <= i3 do begin

  if xyz then break;

  inc(i);
end;

// nja, eigentlich mehr diesem, wenn man bedenkt,
// daß Delphi i3 nur zu Begin der Schleife auswertet und das ergebnis zwischenspeichert

i := i2;
e := i3;
while i <= e do begin

  if xyz then break;

  inc(i);
end;

// und Delphi macht intern aus der For-, bzw der 2. While-Schleife dieses

i := i2;
e := i3;
Loop:
if i > e then goto LoopExit;

  if xyz then goto LoopExit;

  inc(i);
goto Loop;
LoopExit:

// PS: das ganze mit Repeat-Until, statt While, sieht etwa so aus

i := i2;
e := i3;
Loop:

  if xyz then goto LoopExit;

  inc(i);
if i <= e then goto Loop;
LoopExit:

// alles ohne CodeOptimierung

so und jetzt sage mal einer GOTO / Exit / Break seien so schlecht, wenn intern eh alles auf GOTO+IF aufbaut


Am Ende hat alles seine Vor- und Nachteile.

Und ich versuch das zu verwenden, welches in der entsprechenden Situation am Übersichtlichsten/Einfachsten ist. :angel:

[add] *rote kästen ignorier*


[add]
Nur hier sollten endlich mal alle den Unterschied zwischen EXIT und Break/Continue begreifen

Exit - beendet die Prozedur/Funktion
Break - beendet die Schleife

[mirage228]

Also solange du weißt was du tust, kannst du Break und Exit wohl verwenden (es compiliert und läuft ja ordentlich :mrgreen:)
Aber so eine Zeile mit "if .. then Exit" könnte ggf. bei langen Code schon mal übersehen werden, besonders wenn es irgendwo mitten im Code ist...

Ansonsten verweise ich gerne auf einen 5 Jahren alten Thread von mir zum selben Thema:
Break schlechter Programmierstil? :)

Viele Grüße

[turboPASCAL]

Man kanns ja auch mit Goto lösen wen man Break oder Exit nicht mag.

Nö. :mrgreen:



// Edit: Och manno, himitsu hats ja schon geschrieben... :(

[Tyrael Y.]

Jeder Code der

1. gut wartbar ist
2. keine performanceeinbußen eingeht
3. die Funktionalität nicht einschränkt

ist der RICHTIGE Code.

Ob du Exit, Break oder sogar Goto benutzt ist irrelevant.PUNKT.

[nicodex]

Zitat:

Zitat von burn

Oft genug habe ich jetzt schon in der DP gelesen, daß
die Benutzung von Break und Exit schlechter Programmier-Stil ist.

Wenn sie nicht jeweils ihre Daseinsberechtigung hätten, dann gäbe es nur eines oder gar keines dieser Sprachkonstrukte.

Man könnte eher Fragen warum der Parameter nicht "const" ist und warum Exit anstatt Break (hier ausreichend) verwendet wird. Es gibt nicht die richtige Lösung, sondern nur bessere und schlechtere Lösungen. Was "besser" ist, hängt von den Anforderungen, den Umständen und eigenen Entscheidungen ab.

[burn]

@himitsu

Nur damit kein Mißverständnis entsteht:
Ich weiß was Break / Exit machen ... Mir geht lediglich darum
warum ich die nicht verwenden soll ...

mfg Burn

[DeddyH]

Ich oute mich jetzt auch mal als schlechten Programmierer, da ich öfter solche Dinge hier verwende:

Delphi-Quellcode:

procedure TuWas;
begin
  if not unabdingbare_Ausgangsbedingung then exit;
  //hier dann der eigentliche Code
end;

[Tyrael Y.]

Zitat:

Zitat von DeddyH

Ich oute mich jetzt auch mal als schlechten Programmierer, da ich öfter solche Dinge hier verwende:

Delphi-Quellcode:

procedure TuWas;
begin
  if not unabdingbare_Ausgangsbedingung then exit;
  //hier dann der eigentliche Code
end;

Das ist völlig vernünftiger Code...siehe mein Post darüber.

[burn]

@DeddyH

Genau so mach ich das auch immer und
ich versteh nicht was daran schlecht sein soll.

Ich finde den Code so einfach lesbarer (Meine Meinung)

Burn

[himitsu]

das in #23 von DeddyH mach ich auch öfters

(schreibe oftmals mehrere Befehle in eine Zeile und da kann ich den gesparrten Platz bezüglich der Einrückung schon gut gebrauchen ... außerdem wird da eine Zeile, für's END gesparrt)

@burn
hatte erst alle, statt einige geschrieben ... also hab nicht unbedingt dich gemeint :angel:


PS: wißt ihr wie schön man ein GOTO verwenden kann, wenn man mit BREAK nicht mehrere Schleifchen auf einmal verlassen kann? (ich vermisse sowas wie Break(3); für's Verlassen der letzen 3 Ebenen )

[DeddyH]

Ich denke mal, break und exit können dann in eine Falle führen, wenn sie in sehr weit verschachtelten Codes mittendrin verwendet und daher irgendwann übersehen werden können. Da ist dann eine anständige Schleifenbedingung "selbstredender". Aber wie ich schon im anderen Thread gesagt habe, man sollte diese Möglichkeiten nicht generell verteufeln, überlegt und mit Bedacht eingesetzt können Sie IMHO sinnvoll eingesetzt werden (siehe mein Beispielcode).

[jfheins]

Ich finde eigentlich auch nichts schlimmes an break oder Exit :gruebel:

Ich meine ich finde sowas:

Code:

forschleife
begin
  if (bed_1 || bed_2)
    break;

  if (bed_3)
    continue
  else if (weltuntergang)
    exit;

// Code

  if (sonderfall)
    continue;

 // Code
end;

Viel schöner als das mit einem Riesenbatzen logischer Verknüpfungen im while-Kopf zu lösen.

Spätestens ab 3 voneinander Abhängigen Bedingungen sieht der while-Kopf dann nur noch unübersichtlich aus.

Evtl. kann man in manchen Fällen statt einem Exit eine Exception werfen (z.B. Leere Liste sortieren).

Aber grundsätzlich finde ich diese Schlüsselwörter zur Schleifensteuerung sinnvoll und möchte sie nicht um jeden Preis in die while-Bedingung reinquetschen wollen ;)

goto ist da deutlich unübersichtlicher als ein break an der richtigen Stelle. (Wir brauchen ein ComeFrom ^^)

Man sollte imho allg. darauf achten, dass der Code verständlich ist und wann was getrtan wird. Wenn ich am Schleifenkopf 5 Variablen mit 7 Operatoren verknüpfe blicke ich da ne Woche später nicht mehr durch ...

@himitsu ganz oben: Ob der Compiler aus meiner Schleife goto's macht, oder nicht ist mir egel, solange er sich nicht darin verheddert ^^

@himitsu nicht ganz oben: In seperate Funktionen auslagern? ==> Exit ^^

[nicodex]

Zitat:

Zitat von himitsu

(ich vermisse sowas wie Break(3); für's Verlassen der letzen 3 Ebenen )

Viel Spaß beim Modifizieren des Quellcodes, wenn sich die Anzahl der Blöcke ändert ;)

[himitsu]

Zitat:

Zitat von nicodex

Viel Spaß beim Modifizieren des Quellcodes, wenn sich die Anzahl der Blöcke ändert ;)

nja, dazu dann noch 'ne Variante einer benannten While/Repeat-Schleife und es paßt :mrgreen:

Delphi-Quellcode:

while Bedingung name 'xyz' do begin
  while Bedingung do begin

    Break('xyz');

  end;
end;

wobei es so nach Speicher-/Rechenleistung wohl besser wär,
dazu leider unverständlicher (schön benannter Name <> Zahl), abgesehn bei Verwendung von Konstanten

Delphi-Quellcode:

while Bedingung id 123 do begin
  while Bedingung do begin

    BreakID(123);

  end;
end;

ein

Delphi-Quellcode:

with name1:irgendwas do
  with name2:irgendwas do

oder gar //

with name1:irgendwas, name2:irgendwas do

würde sich in Delphi auch gut machen

[burn]

Also um das ganze nochmal auf den Punkt zu bringen:

Break/Exit sind DOCH kein schlechter Stil, wenn man diese
sinnvoll einsetzt und der Code lesbar bleibt.

Besten Dank für eure Meinungen

und Tschüss


mfg Burn