Mein Informatiklehrer sagt, dass

JustAnotherNoob schrieb:

und break hat insofern den selben Sucheffekt wie goto, weil du nun nicht mehr beim lesen des Schleifenkopfes sagen kannst, wann die Schleife verlassen wird.

Da gibt's sicherlich genug Gegenbeispiele, was die Lesbarkeit von Schleifen ohne break bzgl Abbruchbedingung angeht. ZB das hier:

bool wiederholen = true;
  do {
    AAA
    wiederholen = ...; // Test
    if (wiederholen) {
      BBB
    }
  } while (wiederholen);

Hier ist es noch viel schlechter mit der Lesbarkeit. Alternativ bleibt "code duplication"

AAA
  while (...) {
    BBB
    AAA
  }

welches ich immer noch zugunsten von

for (;;) {
    AAA
    if (!...) break;
    BBB
  }

ablehnen würde.

Gruß,
SP

camper

Simon2 schrieb:

Hi,

ich habe nur mal kurz geschaut, aber tut's nicht auch:
...
   if((a+b+c+d!=26)   ||
      (a*b*c*d)%2!=0) ||
      (c!=d) ||
      !istPrim(100*b+10*c+d))
         cout<<a<<b<<c<<d<<'\n';
?
(OK ||-operator sollte nicht überladen sein)

Gruß,

Simon2.

War auch mein Gedanke. Andererseits repräsentiert das eine anderer Denkweise:
Indem wir alle Fälle zu eliminieren, die garantiert unerwünscht sind, bleibt nur das richtige Ergebnis übrig. Das ist der Ausgangscode.

Schreiben wir hingegen eine einzige Bedingung hin ist das konstruktiv: wir formulieren, wie das Ergebnis beschaffen sein muss. Das ist dann also mehr als eine bloße Änderung des Codestils.

Nexus

Interessante Diskussion, die daraus entstanden ist.

Ich wollte eigentlich nicht den Eindruck vermitteln, dass break und continue immer gut seien; eher, dass sie nicht zwingend schlecht sind. Ich verwende sie zwar ab und zu, aber versuche sie zu vermeiden, wenn es schön ohne geht.

Meiner Meinung nach ist es in diesem Fall didaktisch nicht sinnvoll, Aussagen wie die des Lehrers zu machen. Bei goto ist das etwas anderes, weil sich da die meisten Leute einig sind, dass goto in 99% der Fälle zu Spaghetticode führt. Da ist es besser, als Lehrer verschweigt man das eine Prozent, aber hält Anfänger davon ab, garantierte Fehler zu machen. Die Macht von continue und break ist nichts gegen goto , das sieht man alleine schon daran, dass goto die anderen beiden nachbilden kann. Entsprechend ist die Fehleranfälligkeit um ein Vielfaches kleiner als bei goto .

Bei break und continue sind die Meinungen betreffend Codestil – wie Mitleid angetönt hat – viel differenzierter. Gerade deshalb halte ich solche Aussagen für unangebracht. Wenn die Schüler nicht neugierig wie freakC++ sind, behalten sie ihren Glauben und gehen voreingenommen Probleme an. Gut möglich, dass sie durch Workarounds hässlicheren Code schreiben, als wenn sie die bösen Schlüsselwörter benutzt hätten. Und das alles, weil ihnen jemand gesagt hat, dass continue und break böse sind.

Das muss natürlich nicht zwingend so sein, aber oft geht es in die Richtung. Von daher bin ich relativ skeptisch gegenüber solchen Behauptungen. Vielleicht kommt das auch ein wenig davon, dass in unserem Forum ab und zu solche aufgeschnappten Halbwahrheiten kursieren (Optimierungsüberlegungen == Premature Optimization, C ist unsauber, Zeiger sind gefährlich, virtual ist langsam...).

ich würde vorschlagen:

bool liesZahlZwischenEinsUndZehn(int& zahl);

int zahl;
while(!liesZahlZwischenEinsUndZehn(zahl))
{
    // Fehlermeldung
}

damit nix doppelt ist

Simon2

camper schrieb:

...War auch mein Gedanke. Andererseits repräsentiert das eine anderer Denkweise:
Indem wir alle Fälle zu eliminieren, die garantiert unerwünscht sind, bleibt nur das richtige Ergebnis übrig. Das ist der Ausgangscode.

Schreiben wir hingegen eine einzige Bedingung hin ist das konstruktiv: wir formulieren, wie das Ergebnis beschaffen sein muss. Das ist dann also mehr als eine bloße Änderung des Codestils.

Das stimmt natürlich.
Aber ich bevorzuge Zweiteres auch inhaltlich. Natürlich kann man Beides falsch machen, aber Ersteres drückt für mich (auch wegen der abgeschlossenen statements) weniger die Verbindung der Prüfungen untereinander aus. Es hat so ein wenig den Charakter des "Ach ja - und das auch noch".

Gruß

Simon2.

Simon2

Nexus schrieb:

...Gut möglich, dass sie durch Workarounds hässlicheren Code schreiben, als wenn sie die bösen Schlüsselwörter benutzt hätten. Und das alles, weil ihnen jemand gesagt hat, dass continue und break böse sind.
...

Wäre mal ein interessantes Experiment:
50% der Schüler lernen break und continue mit derselben "Wertfreiheit" kennen wie if und for.
Die andere Hälfte wird vor der Benutzung von break/continue gewarnt.
... und am Ende des Schuljahres schaut man, wer den häßlicheren Code geschrieben hat.

Gruß,

Simon2.

Vermutlich will der Informatiklehrer vermeiden, daß Schleifen zwei und mehr Laufbedingungen kriegen. Das wäre schlechter Stil.

life

Dravere schrieb:

Um die Schleife zu verstehen, muss du sie in deinem Kopf wieder entpacken und hast dann im Kopf die Codeduplizierung.

Ahja..

freakC++

Vermutlich will der Informatiklehrer vermeiden, daß Schleifen zwei und mehr Laufbedingungen kriegen. Das wäre schlechter Stil.

Das sehe ich aber nicht so. In den modernsten Büchern finden sich for-Schleifen, die mit mehreren Bedingungen arbeiten. Warum sollte man unnötig viele Schleifen erstellen wenn man ähnliche Bedingungen auch gleich in den Kopf schreiben kann?

So weit konnte mein Lehrer gar nicht denken, denn das kam richtig rausgeschossen also ob das wohl das Normalste der Welt sei. Wie als wenn ich geftragt hätte, ob ich void main() oder int main() schreiben soll. Heutzutage bevorzugt jeder das zweite!!!

lg, freakC++

Habt ihr einmal bedacht, dass der Lehrer es mit Anfängern zu tun hat und diese davon abhalten will unleserlichen Spaghetti-Code zu produzieren? Ein Lehrköper muss eben teilweise pauschal antworten, da er nicht die Zeit hat wie ihr über 100 Seiten einen Flameware zu entfachen, sondern den Stoff durchbringen will.

volkard

Kenner des Lehrers schrieb:

Habt ihr einmal bedacht, dass der Lehrer es mit Anfängern zu tun hat und diese davon abhalten will unleserlichen Spaghetti-Code zu produzieren? Ein Lehrköper muss eben teilweise pauschal antworten, da er nicht die Zeit hat wie ihr über 100 Seiten einen Flameware zu entfachen, sondern den Stoff durchbringen will.

Quatsch!
Man kann sagen, dass break und continue schlechter Programmierstil sind, und damit lügen.
Man kann sagen, dass break und continue Signale für schlechten Programmierstil sind und anzeigen, daß man den Code nochmal überdenken sollte, und damit wahr haben.
Oder man macht's wie ich und sagt anfangs mindestens einmal pro Stunde, daß alle Generalisierungen falsch sind, und später kann ich dann wieder sagen "break und continue sind schlechter Programmierstil!", es wird ja einer widersprechen und sagen "aber es gibt doch bestimmt Fälle, wo es anders ist(?)" und ich sage "Mist, Du hast recht, ja, ich kann mir Fälle vorstellen." und wieder sind zwei aufgewacht; manche warten auch nur darauf, daß ich mich wieder zum Kasper mache.

volkard schrieb:

und damit wahr haben.

http://www.google.de/#hl=de&q="und+damit+wahr+haben."&btnG=Google-Suche&meta=&aq=f&fp=eb7d8eb6a2f89501
http://www.google.de/#hl=de&q="und+damit+recht+haben."&meta=&fp=21aa8cd8ca294c3a

volkard

wer sagt denn sowas schrieb:

volkard schrieb:

und damit wahr haben.

http://www.google.de/#hl=de&q="und+damit+wahr+haben."&btnG=Google-Suche&meta=&aq=f&fp=eb7d8eb6a2f89501
http://www.google.de/#hl=de&q="und+damit+recht+haben."&meta=&fp=21aa8cd8ca294c3a

Mist, Du hast recht.

It0101

Also bei mir enthält fast jede Schleife ein "break". Man sucht etwas, findet es und bricht die Schleife ab.Natürlich kann man auch die Bedingung in die Schleife reinschreiben, aber ein Break ist auch für fremde Code-Leser ( oder ich nach 4 Wochen ) manchmal einfach schneller zu verstehen. Man sieht die Bedingung und das break. Für mich eindeutig einfacher.

Aber andere mögen das anders sehen.

Simon2

It0101 schrieb:

...Natürlich kann man auch die Bedingung in die Schleife reinschreiben...

.. die deswegen auch "Abbruchbedingung" heißt. :p
Ich persönlich finde die Vielfältigkeit der Ausdrucksmöglichkeiten mit while und for einfach sprechender.
So assoziiere ich mit "for" gleich das "Abarbeiten einer vorgegebenen Menge" und "while" ein "Wiederholen, solange ein bestimmter Zustand besteht" (bzw. bis ein bestimmter Zustand erreicht ist).

Das spiegelt bestimmte "Standardschleifen" wider - und diese Standardfälle sind einfacher wiederzuerkennen, wenn man sie entsprechend nennt.
(Aus demselben Grund bin ich auch für die vernünftige Verwendung der <algorithm>-Funktionen)

Nicht jede Fachlichkeit kann ausschließlich durch die Struktur

while(true) {
   a();
   if(irgendwas()) break;
   b();
   if((irgendwas_anderes()) break;
   ...

beschrieben werden.
... ist ein wenig vergleichbar mit dem Einführen der Multiplikation in der Grundschule: Es gibt Schüler, die das für überflüssig halten, weil man sie ja auch durch Addition ausdrücken kann ... aber irgendwann bricht man sich damit die Finger.

Gruß,

Simon2.

DeepCopy

Mein Informatikprofessor in einer der ersten Vorlesungen zu C++

"Das break ist zu vermeiden, da das Schleifenkonstrukt in einem unbestimmten Zustand verlassen wird, es ist unter Umständen mit unerwünschten Nebeneffekten zu rechnen, viel besser ist es die Abbruchbedingung durch die Schleifenbedingung selbst herbei zuführen." dies sei... so der Prof.: "Guter Programmierstiel!"

/** schlechter Stil **/
for(int i = 0; i < 4; i++)
{
  /* mach was */ 
  break; // <- ganz böse
}

/** guter Stil **/
for(int i = 0; i < 4; i++)
{
  /* mach was */ 
  i = 4; // <- Gut
}

Ich gestehe ich halte mich bei meinen Programmen auch nicht daran und verwende break und continue immer dann wenn ich es brauche.

camper

Hast du mal nachgefragt, was ein "unbestimmter Zustand" sein soll, und unter welchen Umständen diese unerwünschten Nebeneffekte auftreten?

volkard

camper schrieb:

Hast du mal nachgefragt, was ein "unbestimmter Zustand" sein soll, und unter welchen Umständen diese unerwünschten Nebeneffekte auftreten?

Das ist leicht. Wie alle noch existierenden Pascaloiden Krankheiten liegt es an der Absenz von Konstruktoren und hat keine Aussagekraft für C++.

/** guter Stil **/ 
for(int i = 0; i < 4; i++) 
{ 
  FILE* fi=fopen();
  ...mach was
  i = 4; // <- Gut 
  ...mach nochwas
  fclose(fi);
}

DeepCopy

camper schrieb:

Hast du mal nachgefragt, was ein "unbestimmter Zustand" sein soll, und unter welchen Umständen diese unerwünschten Nebeneffekte auftreten?

Ich könnte Ihm ja mal zum Spass eine Mail mit der Frage senden

DeepCopy

volkard schrieb:

Wie alle noch existierenden Pascaloiden Krankheiten liegt es an der Absenz von Konstruktoren

Wie bitte..? War das jetzt nur mal schnell Pascal schlecht machen? Was haben den Konstruktoren mit Schleifenbedingungen gemeinsam? Das verstehe ich nicht.