3. Mein Informatiklehrer sagt, dass

Mein Informatiklehrer sagt, dass

  • ?

    JustAnotherNoob schrieb:

    ich dachte die Argumente wären allen bekannt 🙄

    Welche sind denn das? Bring das doch mal auf'n Punkt!

    Gesprungen wird immer irgendwo irgendwie, zB auch beim Funktionsaufruf. :p

    Das wichtige dabei ist doch die Lesbarkeit. Wenn ich ein "goto" sehe, dann muss ich erstmal die Sprungmarke suchen, um zu wissen, wo's weiter geht. Das ist schlechte daran. Es hat auch zur Folge, dass es schwieriger wird, sich von der Korrektheit des Programms zu überzeugen.

    Wie sieht es mit break, continue und return aus? Wenn Deine Schleifen mehrere Seiten lang sind, hast Du sowieso etwas falsch gemacht. Bei break und continue ist sofort klar, wo's weitergeht. Mit return springe ich aus der Funktion heraus. Willst Du mir jetzt erzählen dass die Nutzung von break, continue und return die Lesbarkeit verschlechtert? Wie würdest Du denn das Beispiel von tntnet mit der "and-a-half"-Schleife umsetzen?

    So vielleicht? (Mit Zusatzvariable)

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

    Oder so vielleicht? (Mit Code Duplication)

    AAA
  while (...) {
    BBB
    AAA
  }

    ?

    Ist doch alles Käse!

    Gruß,
    SP

    0
  • ?
     

    #include <iostream> 

using namespace std; 

bool istPrim(int kandidat) 
{ 
   bool prim=true; 

   for(int i=2;i<=kandidat-1;i=i+1) 
   { 
      if(kandidat%i == 0) 
      { 
         prim=false; 
         return prim; 
      } 
   } 
   return prim; 
} 

int main() 
{ 
    for(int a=0;a<=9;++a) 
    { 
        for(int b=0;b<=9;++b) 
        { 
            for(int c=0;c<=9;++c) 
            { 
                for(int d=0;d<=9;++d) 
                { 
                    if(a+b+c+d!=26)
                        ;
                    else if((a*b*c*d)%2!=0) 
                        ; 
                    else if(c!=d) 
                        ; 
                    else if(!istPrim(100*b+10*c+d)) 
                        ; 
                    else
                        cout<<a<<b<<c<<d<<'\n'; 
                } 
            } 
        } 
    } 
    return 0; 
}
    0
  • V

    adfkhl schrieb:

    #include <iostream> 

using namespace std; 

bool istPrim(int kandidat) 
{ 
   bool prim=true; 

   for(int i=2;i<=kandidat-1;i=i+1) 
   { 
      if(kandidat%i == 0) 
      { 
         prim=false; 
         return prim; 
      } 
   } 
   return prim; 
} 

int main() 
{ 
    for(int a=0;a<=9;++a) 
    { 
        for(int b=0;b<=9;++b) 
        { 
            for(int c=0;c<=9;++c) 
            { 
                for(int d=0;d<=9;++d) 
                { 
                    if(a+b+c+d!=26)
                        ;
                    else if((a*b*c*d)%2!=0) 
                        ; 
                    else if(c!=d) 
                        ; 
                    else if(!istPrim(100*b+10*c+d)) 
                        ; 
                    else
                        cout<<a<<b<<c<<d<<'\n'; 
                } 
            } 
        } 
    } 
    return 0; 
}

    das continue dürckt mehr sofort aus, nämlich "dieser fall ist erledigt, sofort den nächsten ausprobieren!".

    0
  • Administrator

    Sebastian Pizer schrieb:

    Bei break und continue ist sofort klar, wo's weitergeht.

    Wo es weitergeht ist klar. Herausfinden wie der Algorithmus aussieht, kann* allerdings erschwert werden. Durch ein break kann man zum Beispiel Codeduplizierung entfernen, wie es tntnet vorgeführt hat. Dadurch hast du aber eben irgendso eine halbe Schleife. Um die Schleife zu verstehen, muss du sie in deinem Kopf wieder entpacken und hast dann im Kopf die Codeduplizierung. Daher ist auch Codeduplizierung nicht einfach nur grundlegend schlecht und wenn man das dann noch in Funktionen aufteilt oder auf Variablen verteilt (z.B. die message Variable in meinem vorherigen Code), dann sehe ich eher Vorteile in der Lesbarkeit.

    *Ich möchte, dass man dieses kann nicht vergisst: kann werden != wird 😉

    Grüssli

    0
  • J

    Gesprungen wird immer irgendwo irgendwie, zB auch beim Funktionsaufruf.

    Der Unterschied beim Funktionsaufruf ist, dass dieser bewusst implementierungsdetails versteckt.
    Im Gegensatz zu Sprunganweisungen wird der Lesefluss daher nicht unterbrochen.

    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.

    0
  • S

    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.

    0
  • V

    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.

    Ja. Aber nicht ganz so schlimm wie goto, weil man wenigstens weiß, daß ans Ende der Schleife gesprungen wird.
    return ist da noch ein wenig besser, weil man weiß, daß die ganze Funktion beendet wird.

    0
  • ?

    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

    0
  • C
    Mod

    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.

    0
  • N

    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...).

    0
  • ?

    ich würde vorschlagen:

    bool liesZahlZwischenEinsUndZehn(int& zahl);

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

    damit nix doppelt ist

    0
  • S

    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.

    0
  • S

    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.

    0
  • ?

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

    0
  • L

    Dravere schrieb:

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

    Ahja.. 🤡

    0
  • F

    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++

    0
  • ?

    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.

    0
  • V

    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.

    0
  • ?

    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

    0
  • V

    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.

    0
Anmelden zum Antworten