Bedingung aufstellen
-
µngbd schrieb:
Aber Endlosschleifen sind eben böse, Punkt.
das macht doch keinen unterschied. do{...}while(x) wird auch zur endlosschleife, wenn die bedingung im 'while' nie false wird.
-
Gehen tut das mit dem for( ; ; ) ebenso wie ein while(true) schon.
Aber für was bitte gibt es denn eine Abbruchbedingung? Die ist schön übersichtlich am Anfang/Ende der Schleife platziert. wenn der Code in der Schleife recht umfangreich wird, darf man ewig suchen, bis man alle break/continue/... zusammen hat, um die Logik hinter dem Code zu verstehen.
Man löst ein Problem ja nicht nur, dass es gelöst ist, sondern dass man auch später wieder weiß wie sie funktioniert
-
;fricky schrieb:
µngbd schrieb:
Aber Endlosschleifen sind eben böse, Punkt.
das macht doch keinen unterschied. do{...}while(x) wird auch zur endlosschleife, wenn die bedingung im 'while' nie false wird.
Sehe ich genauso. Ich hab früher, als ich noch solche Stilgesetze geglaubt hab, immer wieder mal die Bedingungen von Schleifen solange umgeschrieben, bis ich kein break/continue/goto mehr brauchte. Am Ende war dann die Bedingung zwei Zeilen lang, und so kunstvoll geklammert, dass man ohne Kopfschmerzen nicht mehr durchsteigen konnte.
Andererseits ist l'abra d'or anderer Meinung:
l'abra d'or schrieb:
Die ist schön übersichtlich am Anfang/Ende der Schleife platziert. wenn der Code in der Schleife recht umfangreich wird, darf man ewig suchen, bis man alle break/continue/... zusammen hat, um die Logik hinter dem Code zu verstehen.
Klar, das kann passieren. Ich glaub trotzdem nicht daran, dass man deshalb allgemeine Stilgesetze entwerfen sollte. Manchmal ist es so klarer, manchmal anders. Ich nenne das die Freiheit der Rede.
-
l'abra d'or schrieb:
Aber für was bitte gibt es denn eine Abbruchbedingung? Die ist schön übersichtlich am Anfang/Ende der Schleife platziert. wenn der Code in der Schleife recht umfangreich wird, darf man ewig suchen, bis man alle break/continue/... zusammen hat, um die Logik hinter dem Code zu verstehen.
ich finde es unübersichtlicher, wenn man extra was negieren muss, nur damits zu irgendwelchen vorgegebenen schleifenkonstrukten passt. manche basteln sich sogar noch 'ne eigene abbruchvariable zurecht, damit es passt (<--*scheusslich*). ich finds am besten, wenn man's ganz straight programmiert, so wie man denkt, dann kannste auch auf kommentare verzichten. aber ist wohl geschmackssache.
btw, zudem sind breaks innerhalb von for(;;)-schleifen flexibler, kannst z.b. sowas machen:for(;;) { ... anderer code a = calculate_a(); if (a==4); break; // berechnung von b nicht mehr nötig ... noch mehr code b = calculate_b(); if (b==1) // jetzt reichts aber wirklich break; ... und noch was }^^ springt auch raus, wenn b==4 oder a==1 oder beides.
µngbd schrieb:
Ich hab früher, als ich noch solche Stilgesetze geglaubt hab, immer wieder mal die Bedingungen von Schleifen solange umgeschrieben, bis ich kein break/continue/goto mehr brauchte.
dann haste damals switch/case wohl auch verabscheut *fg*
-
Whatever, jedem das Seine.
Nochmal für den OP.do { ... }while(a != 4 || b != 1);Damit das Verständnis erhalten bleibt, kann man statt "||" auch "or" verwenden.
do { ... }while(a != 4 or b != 1);Führe die Schleife solange aus, bis a 4 ODER b 1 entspricht.
-
FreakY<3Cpp schrieb:
Damit das Verständnis erhalten bleibt, kann man statt "||" auch "or" verwenden.
do { ... }while(a != 4 or b != 1);Führe die Schleife solange aus, bis a 4 ODER b 1 entspricht.
Die Schleife soll abgebrochen werden, falls a==4 oder b==1, oder beides eintritt.
while(a!=4 || b!=1) bricht aber eben nur ab, wenn a==4 UND b==1!
Mannmannmann
-
FreakY<3Cpp schrieb:
Damit das Verständnis erhalten bleibt, kann man statt "||" auch "or" verwenden.
^^dafür musste aber <iso646.h> includen. or, and, not, usw. sind keine schlüsselwörter sondern #defines
-
;fricky schrieb:
manche basteln sich sogar noch 'ne eigene abbruchvariable zurecht, damit es passt (<--*scheusslich*)
Das sind sicher C++ler, die glauben, dass jeder Compiler Gedanken lesen kann.
;fricky schrieb:
dann haste damals switch/case wohl auch verabscheut *fg*
Stimmt, ganz am Anfang hab ich nicht verstanden, wozu das gut sein soll. Irgendwann bin ich dann dahintergekommen, und damals hab ich wohl begonnen, mir meine eigene Meinung zurechtzulegen. Bin immer noch nicht damit fertig.
Schon die Propheten waren in dem Punkt nicht ganz eindeutig:
K&R (frei zitiert) schrieb:
C hat goto, kann beliebig missbraucht werden. Wir bringen trotzdem einige Anwendungsbeispiele:
[...]Jedenfalls bin ich einverstanden mit:
l'abra d'or schrieb:
Man löst ein Problem ja nicht nur, dass es gelöst ist, sondern dass man auch später wieder weiß wie sie funktioniert
;fricky schrieb:
ich finds am besten, wenn man's ganz straight programmiert, so wie man denkt, dann kannste auch auf kommentare verzichten.
Da ist sicher was dran.
-
;fricky schrieb:
kannste es dir aber auch ganz einfach machen:
for (;;) { // // ... anderer code // if (a == 4 || b == 1) break; }^^ deine frage wörtlich in C umgewandelt. *fg*
Kein Wunder das in diesem Forum jeder C verabscheut wenn du solchen Code postest. Das ist übelster Anfänger-Code und wenn ich das sehe muss ich sehr an deinen Fähigkeiten zweifeln.
-
player4245 schrieb:
Kein Wunder das in diesem Forum jeder C verabscheut wenn du solchen Code postest.
Jeder...?
http://www.cliquenabend.de/spiele/asterix/asterix1.jpg
-
Einigen wir uns auf: die meisten
-
player4245 schrieb:
Einigen wir uns auf: die meisten
Hast du eine Statistik?
-
nicht unbedingt aber erfahrung
-
µngbd schrieb:
;fricky schrieb:
manche basteln sich sogar noch 'ne eigene abbruchvariable zurecht, damit es passt (<--*scheusslich*)
Das sind sicher C++ler, die glauben, dass jeder Compiler Gedanken lesen kann.
oder die armen schweine, die nach misra-regeln u.ä. coding-styles programmieren müssen. man versucht, typische C-fehlerquellen auszuschliessen, macht aber durch seltsame umwege zur einhaltung der regeln den code weniger verständlich. es gibt nun mal nichts geschenkt. *fg*
µngbd schrieb:
...und damals hab ich wohl begonnen, mir meine eigene Meinung zurechtzulegen. Bin immer noch nicht damit fertig.
das ist doch gut so, allerdings gibts kein 'fertig werden'.
player4245 schrieb:
Das ist übelster Anfänger-Code ...
ja, den versteht jeder anfänger. ist doch gut, oder nicht?
-
Dieser Code sah alles andere als gut aus. Sicher gibt es Fälle in denen sich ein solches Konstrukt nicht vermeiden lässt, aber das ist gewiss keiner davon.
-
player4245 schrieb:
Dieser Code sah alles andere als gut aus.
ich kann deine abneigung ja irgendwie verstehen, 'break' ist der kleine bruder von 'goto'. von mir aus mach 'ne klammer drum, ein 'not' davor und nimm es als 'while'-ausdruck. ich sagte ja schon: ist geschmackssache.
-
Ich hab keine Abneigung gegen break und continue. Ich bin auch kein Anhänger von diesen "... ist böse" Sätzen, nur dieses Konstrukt finde ich sieht einfach stümperhaft aus.
-
player4245 schrieb:
Ich hab keine Abneigung gegen break und continue. Ich bin auch kein Anhänger von diesen "... ist böse" Sätzen
setsam, ich dachte immer du bist C++ fan. *fg*
player4245 schrieb:
...nur dieses Konstrukt finde ich sieht einfach stümperhaft aus.
so unterschiedlich sind die standpunkte. ich finde es z.b. stümperhaft, wenn man dinge nicht vereinfacht.
-
Ich mag beide Sprachen. C++ benutz ich aber eher in grösseren Projekten. Ich mache die Dinge auch so einfach wie möglich, nur finde ich, dass man möglichst immer eine Abbruchbedingung formulieren sollte. In der Schleife kann man dann ruhig break und continue benutzen.
-
;fricky schrieb:
Jedenfalls bin ich einverstanden mit:
l'abra d'or schrieb:
Man löst ein Problem ja nicht nur, dass es gelöst ist, sondern dass man auch später wieder weiß wie sie funktioniert
Ich nicht. Gelöst ist gelöst, das ist ja der Witz an modularer Programmierung. Die Frage ist ja eher, wie man sicherstellen will, daß man nicht immer wieder ähnliche Probleme neu durchkaut.
;fricky schrieb:
ich finds am besten, wenn man's ganz straight programmiert, so wie man denkt, dann kannste auch auf kommentare verzichten. Da ist sicher was dran.
Bin ich wieder einverstanden, am ehesten kommentiere ich Fremdcode, bei Eigenproduktion halte ich mich an die Stackkommentarregel für FORTH. Ich muß nicht mehr wissen, wenn ein Modul funzt und wenn nicht, stimmt eher die Regel:
KOMMENTARE LÜGEN!
;fricky schrieb:
ich kann deine abneigung ja irgendwie verstehen, 'break' ist der kleine bruder von 'goto'. von mir aus mach 'ne klammer drum, ein 'not' davor und nimm es als 'while'-ausdruck. ich sagte ja schon: ist geschmackssache.
Jaja, und viele returns in einer Funktion sind die bösen Stiefschwestern
player4245 schrieb:
Ich hab keine Abneigung gegen break und continue. Ich bin auch kein Anhänger von diesen "... ist böse" Sätzen, nur dieses Konstrukt finde ich sieht einfach stümperhaft aus.
Ja, do .. while wäre naheliegender, aber solange jeder sofort sieht, was Sache ist, ist es doch egal, oder? Über Geschmack läßt sich trefflich wie sinnlos, aber auf jeden Fall endlos debattieren ...
