Hey alle zusammen,
ich habe ein Problem und das ist folgendes. Ich möchte zwei
for-Schleifen miteinander Verknüpfen. Bislang sah das folgendermaßen
aus:
{printf("\nEingabe ungültig! Programm wird beendet!");}
15
}
Jetzt meine Frage, ich habe versucht die zwei for-Schleifen miteinander
zu verbinden aber weiß nicht wie. Ich habe folgendes Versucht, aber da
muss irgendwo ein Zeichenfehler zwischen den beiden Schleifen sein bzw.
es fehlt eine Klammer, Komma o.ä. :
das nächste "Kosmetikproblem" ist die Sache, dass ich meine Schleife mit
einem If-else Konstrukt bauen möchte, es aber nur mit der Variante in
Geschweiften Klammern klappt (siehe oben).
Mein Konstrukt sah folgendermaßen aus:
....
elseprintf("\nEingabe ungültig! Programm wird beendet!");
5
}
Hier fehlt wohl auch ein Ausdruck vor dem else.
Ich bin da gerade etwas ratlos und weiß auch nicht mehr weiter:D
Wäre toll wenn mir da jemand einen Rat eben könnte, wie ich das ganze
etwas schöner machen könnte
--
Quelltext bitte in [ c ] [ /c ] - Tags einschließen.
-rufus
prog234 schrieb:> for(markerEssen=0;markerEssen<5;markerEssen++){&&(markerZusaetze=0;marke> rZusaetze<20;markerZusaetze++){
Eine solche Konstruktion gibt es in C nicht. Du musst zwei
verschachtelte Schleifen benutzen wie oben schon. Du kannst aber die
gesschweiften Klammern, bis auf bei der innersten Schleife weglassen.
prog234 schrieb:> das nächste "Kosmetikproblem" ist die Sache, dass ich meine Schleife mit> einem If-else Konstrukt bauen möchte, es aber nur mit der Variante in> Geschweiften Klammern klappt (siehe oben).
Da verstehe ich die Frage nicht wirklich. Schleifen gibts nicht mit
if-else Konstrukt sondern nur mit einer Bedingung und solange diese wahr
ist wird die Schleife durchlaufen.
Bei deinem anderen Problem mit dem else fehlt eine Klammer für den
true-Zweig der if Bedingung. So geht es:
1
if(bedingung)
2
{
3
// hier nichts
4
}
5
else
6
{
7
printf("\nEingabe ungültig! Programm wird beendet!");
8
}
Wobei es natürlich mehr Sinn macht die Bedingung umzuformulieren.
Entweder mit if(!bedingung) oder in deinem Fall kann man die negation
auch in die einzelnen Bedingungen ziehen. Das sieht dann so aus:
Auch mit den von mir nachgetragenen Codeformatierungstags ist das
grauenhaft. Von formatiertem Quelltext hältst Du nichts?
Leerzeichen können Quelltext lesbarer machen. Einrückungen lassen
erkennen, wo funktionale Blöcke sind.
Deine "Verknüpfung" zweier For-Schleifen kann so nicht funktionieren.
Hast Du schon mal einen Blick in ein C-Buch geworfen?
Zwar kann man in einer for-Schleife mehrere Laufvariablen
zusammenfassen, aber es gibt nur ein Schleifenabbruchkriterium, so daß
Du nicht zwei unterschiedlich oft zu durchlaufende Schleifen in einer
zusammenfassen kannst.
prog234 schrieb:> Wäre toll wenn mir da jemand einen Rat eben könnte, wie ich das ganze> etwas schöner machen könnte
- Jeden Block um zwei Leerzeichen oder so einrücken
- Jede Blockklammer in einer eigenen Zeile
Ich würde "marker" weglassen. Bringt nichts (innerhalb der paar Zeilen
ist eh klar, dass es sich um den Index handelt) und ist in der
Konzentration ätzend zu lesen.
"if(Zusatzstoff !=1 && Zusatzstoff !=2" ... )" könnte man z.B. durch
eine Funktion ersetzen, die ein dort deklariertes statisches Array (mit
den entsprechenden Zusatzstoff-Nummern) durchläuft.
Wenn man dann noch vernünftig formatiert und sinnvolle Namen verwendet,
dürfte das Ganze schon viel besser aussehen.
Und die Zahlen durch Konstanten ersetzen; besonders die Längen (5 und
20) sowie die Indizes für datum_des_beispiels, unter denen man sich
sonst gar nichts vorstellen kann.
Rufus Τ. Firefly schrieb:> so daß> Du nicht zwei unterschiedlich oft zu durchlaufende Schleifen in einer> zusammenfassen kannst.
Ach blödsinn, umformen kann man immer!
Schön. Das ist dann auch Code, den jeder Anfänger sofort versteht und
nachvollziehen kann ...
Allein aus Gründen der Wartbarkeit würde ich solche Anfälle von
Genialität gleich wieder entfernen, denn tatsächliche Vorteile hat so
etwas nicht.
Rufus Τ. Firefly schrieb:> Allein aus Gründen der Wartbarkeit würde ich solche Anfälle von> Genialität gleich wieder entfernen, denn tatsächliche Vorteile hat so> etwas nicht.
Das mit der Wartbarkeit stimmt, aber dass es Genial wäre oder Vorteile
brächte habe ich nie behauptet! Ich schrieb sogar "umformen kann man
immer!", wenn man etwas umformt bleibt dessen bedeutung gleich, der
Compiler könnte also die gleichen instruktionen aus beiden varianten
generieren.
Es gieng mir nur darum aufzuzeigen, dass die Behauptung, dass es nicht
möglich wäre, falsch ist. ( Es war nicht Böse oder Provokativ gemeint )
Vielen Dank für die bisherigen Infos:)
Bezüglich der Schleife habt ihr Recht, das wahr schwachsinnig so etwas
zu probieren.
Daniel A. schrieb:> for(markerEssen=0,markerZusaetze=0;markerZusaetze<20;markerEssen=(++mark
erEssen<5?markerEssen:(markerZusaetze++,0))){
> }
Wie gesagt ich bin Anfänger und Versuche mich gerade daran Programme zu
verstehen und eigenständig zu bearbeiten. Die Initialisierung dieser
Schleifen Verknüpfung verstehe ich ja noch, aber die Bedingung(en) und
Schrittweite(n) verstehe ich nicht. Was bedeutet die Verkettung "<5?"
und hier im Genauen das Fragezeichen. Wäre super, wenn mir das einer
Verdeutlichen könnte:) Ich möchte ja dazu lernen.
Sebastian V. O. schrieb:> Wobei es natürlich mehr Sinn macht die Bedingung umzuformulieren.> Entweder mit if(!bedingung) oder in deinem Fall kann man die negation> auch in die einzelnen Bedingungen ziehen. Das sieht dann so> aus:if(Zusatzstoff==1 || Zusatzstoff==2 || Zusatzstoff==3 ||> Zusatzstoff==6 || Zusatzstoff==9 ||> Zusatzstoff==11 || Zusatzstoff==12 || Zusatzstoff==13 ||> Zusatzstoff==19)> {> printf("\nEingabe ungültig! Programm wird beendet!");> }
Wenn ich diese variante so einbaue, bekomme ich nur eine Ausgabe bei
"wahren" Werten (in diesem Fall die Zusatzstoffe 1,2,3,6,9,11,12,13 und
19). Diese Ausgabe hat sowohl den Menüplan dieses Tages, aber auch die
Ausgabe "Eingabe ungültig! Programm wird beendet!". Diese Ausgabe soll
nur kommen, falls eine andere Eingabe statt der "gültigen" angegeben
wird und nicht generell als Ausgabe angegeben werden. Gebe ich
stattdessen einen "falschen" Wert oder eine negative zahl ein, so kommt
gar keine Ausgabe. :D
Max H. schrieb:> Versuchs mal> so:if(Zusatzstoff!=1&&Zusatzstoff!=2&&Zusatzstoff!=3&&> Zusatzstoff!=6&&Zusatzstoff!=9&&Zusatzstoff!=11&&> Zusatzstoff!=12&&Zusatzstoff!=13&&Zusatzstoff!=19)> printf("\nEingabe ungültig! Programm wird beendet!");
So habe ich das auch gemacht (lediglich die geschweiften Klammern habe
ich weggelassen) und bislang ist das auch die einzige Variante die eine
korrekte Programmausgabe liefert:
if(Zusatzstoff!=1&&Zusatzstoff!=2&&Zusatzstoff!=3&&Zusatzstoff!=6&&Zusat
zstoff!=9&&Zusatzstoff!=11&&Zusatzstoff!=12&&Zusatzstoff!=13&&Zusatzstof
f!=19)
{printf("\nEingabe ungültig! Programm wird beendet!");}
Anscheinend ist das die praktischste oder zumindest die verständlichste
Variante die if-Anweisung zu kreieren.
Ach du gütiger. Ich bin in meiner Arbeitlung auf Arbeit für die Code
Reviews zuständig - so etwas würde da sofort Retoure gehn oder per
Beschluss sofort per "revert" aus dem Repository getilgt.
Magic Values, keine Formatierung, komische Klammernsetzung.
kaese schrieb:> Ach du gütiger. Ich bin in meiner Arbeitlung auf Arbeit für die Code> Reviews zuständig - so etwas würde da sofort Retoure gehn oder per> Beschluss sofort per "revert" aus dem Repository getilgt.>> Magic Values, keine Formatierung, komische Klammernsetzung.prog234 schrieb:> Wie gesagt ich bin Anfänger und Versuche mich gerade daran Programme zu> verstehen und eigenständig zu bearbeiten.
prog234 schrieb:
if(Zusatzstoff!=1&&Zusatzstoff!=2&&Zusatzstoff!=3&&Zusatzstoff!=6&&Zusat
zstoff!=9&&Zusatzstoff!=11&&Zusatzstoff!=12&&Zusatzstoff!=13&&Zusatzstof
f!=19)
> {printf("\nEingabe ungültig! Programm wird beendet!");}>> Anscheinend ist das die praktischste oder zumindest die verständlichste> Variante die if-Anweisung zu kreieren.
Ist Ansichstsache.
Haufenweise 'Nicht gleich' zu verwenden ist nicht unbedingt schlau. Wir
sind nun mal positive Logik gewohnt. D.h. etwas muss erfüllt sein, damit
eine Abhängikeit gilt.
Manchmal ist es einfacher, das NICHT herauszuziehen. Auch gedanklich.
"Wenn es nicht der Fall ist, dass der Zusatzstoff entweder 1 ist oder
der Zusatzstoff 2 ist oder ....
1
if(!(Zusatzstoff==1||
2
Zusatzstoff==2||
3
Zusatzstoff==3||
4
Zusatzstoff==6||
5
Zusatzstoff==9||
6
Zusatzstoff==11||
7
Zusatzstoff==12||
8
Zusatzstoff==13||
9
Zusatzstoff==19))
10
printf(...)
in dieser Variante steht das NICHT an prominenter Stelle und ist kaum zu
übersehen. Manchmal ist es auch schlauer, das Gegenteil anzuführen:
Welche Zusatzstoffe führen zu einem Fehler?
Ein übriges tut auch die Codeformatierung, bei der man auf einen Blick
sehen kann, dass alle Abfragen auf 'gleich' lauten und dass immer
dieselbe Variable im Spiel ist. Ganz im Gegensatz zu deiner Variante,
bei der man erst mal identifizieren muss, wo eigentlich ein Wort anfängt
und wo es aufhört, bei der man sich krumm und dämlich sucht um
rauszufinden, dass es immer um dieselbe Variable geht und das alle
Vergleiche auf != lauten.
Nein. Codeformatierung macht man nicht hinterher, sondern die macht man
gleich! Denn ein ordentlich formatierter Code hilft dir, eine ganze
Latte von Fehlern zu vermeiden. Fehler die dich während der Entwicklung
nur aufhalten und die mehr Zeit kosten, als dich die einmalige
vernünftige Formatierung kostet. Meine Hypothese lautet: Es ist kein
Zufall, das signifikant sehr oft diejenigen mit dem scheuslichsten und
dem am schlechtest zu lesenden Code diejenige mit den dümmsten
Codefehlern sind. Unterstützung bekommt diese Hypothese jede Woche,
jeden Tag hier im Forum.
Seit du 6 Jahre alt bist, hast du dein Gehirn beim Lesen darauf
trainiert, dass zwischen 2 Wörtern ein Leerraum steht. Dein Gehirn ist
in der Lage, Wörter als Einheit zu erfassen ohne dass du großartig
darüber nachdenken musst. Nutze dieses Trainung und befreie dich
wenigstens davon, dass du beim Codelesen ständig mit den Augen den
Buchstabensalat danach absuchen musst, wo eigentlich die Wort bzw.
Begriffsgrenzen sind.
Man kann auch einmal gut überlegen und sich darauf konzentrieren, welche
Zusatzstoffe OK sind und wie man das mittels UND/ODER/wasauchimmer
verknüpft. Dann steckt man diese Erkenntnis in eine Funktion und muss
nie wieder da rein sehen oder sich mit den zig verknüpfungen rumärgern.
1
boolstoff_ist_ok(intzs)
2
{
3
return(zs==1)||(zs==2)/* || ... usw. */;
4
}
Diese neue Funktion stoff_ist_ok() kann man mit wenig Aufwand gleich
nach dem Schreiben testen und sich erstmal darauf konzentrieren, nur
diese eine Funktion richtig hinzubekommen:
1
intmain(void)
2
{
3
/* ###########################################*/
4
/* Testcode */
5
/* nur zum pruefen, ob stoff_ist_ok() funktioniert: */
6
intzusatz;
7
for(zusatz=0;zusatz<17;zusatz++)
8
{
9
printf("Zusatz %d ist ",zusatz);
10
if(stoff_ist_ok(zusatz))
11
printf("OK\n");
12
else
13
printf("giftig\n");
14
}
15
/* Ende Testcode */
16
/* ###########################################*/
17
18
/*
19
Der ganze Rest von main() wird erstmal auskommentiert, bis stoff_ist_ok() das richtige tut.
20
*/
21
}
Hat man diesen Test bestanden, kann man sicher sein, dass diese Funktion
funktioniert und unerwartete Dinge an etwas anderem liegen. Jetzt haut
man den Test-Code wieder raus, den richtigen Code wieder rein und kann
die neue Funktion in der if-Abfrage benutzen:
1
if(!stoff_ist_ok(Zusatzstoff))
2
{
3
printf("Alles falsch, geh weg\n");
4
exit(32);
5
}
Das liest sich fast wie Prosa und man muss an dieser Stelle nicht mehr
über Details der Zusatzstoffe nachdenken.
Mhm,
ich bekomme des öfteren auch Augenkrebs, wenn ich den Codestyle mancher
betrachte( bezieht sich auf die Zusammengefasste for-Schleife).
Meiner Meinung nach ist es hingegen sinnvoll, bei einem if-Statement die
Einzelnen boolschen Ausdrücke in eigene Zeilen zu fassen a la:
1
if(a<b||
2
b<c||
3
sackKartoffeln>sackErdbeeren){//^^
4
5
//Hier der Code
6
}
Dieses Schema lässt sich beliebig erweitern.
Wenn man sich ein solchen Statement ein paar Monate später anschaut,
finde ich den Weg ganz gut Reproduzierbar.
Ach ja. Auch wenn in einem solchen if-Statement die Geschweiften
Klammern weggelassen werden können, finde ich diesen Stil allerdings
alles andere als Sinnvoll.
Darüber scheiden sich allerdings die Geister.
Noch ein Lob. Ich finde finde Variablenbezeichnung des TE sehr gut.
Ich finde es immer wieder schrecklich z.B. mit Mathematikern zu
arbeiten, die Variablen a la : a ,b, a1 o.ä. verwenden.
Oder etwas in dieser Richtung? So würden die Nummern zusammenstehen und
man könnte zum Erweitern einfach die entsprechenden Werte einfügen.
Negieren sollte man meiner Meinung nach besser beim Aufruf.
So oder so würde ich es in eine eigene Funktion setzen; wurde ja auch
schon erwähnt.
Simon schrieb:> Noch ein Lob. Ich finde finde Variablenbezeichnung des TE sehr gut.
Wobei ich "fuenfEssen" nicht so gut finde, denn die Anzahl hat hier
eigentlich nichts im Variablennamen zu suchen.
> Ich finde es immer wieder schrecklich z.B. mit Mathematikern zu> arbeiten, die Variablen a la : a ,b, a1 o.ä. verwenden.
Ja, die Wahl der Namen ist für das Codeverständnis wichtig. Aber auch a,
b, n, i, j etc. haben ihre Existenzberechtigung - z.B. in Formeln
(zumindest manchmal), als primitive Schleifenzähler wie oben sowie als
Namen von Parametern mit unbekannter Bedeutung in
allgemeinen/generischen Funktionen (min, max, ...).
Simon schrieb:> ich bekomme des öfteren auch Augenkrebs, wenn ich den Codestyle mancher> betrachte
Das ist normal. Man kriegt oft schon leichte Formen von Augenkrebs, wenn
man schön formatierten Code anderer Leute betrachtet, nur weil der eben
nach anderen Regeln formatiert wurde als man selbst bevorzugt. Weil
beispielsweise ich statt
1
if(a<b||
2
b<c||
3
sackKartoffeln>sackErdbeeren)
diese Variante favorisiere, auch wenn die Editoren oft versuchen, mir
dabei einen Strich durch die Rechnung zu machen:
1
if(a<b
2
||b<c
3
||sackKartoffeln>sackErdbeeren)
> Darüber scheiden sich allerdings die Geister.
Auch deshalb, weil man durch schöne Formatierung mitunter derart Zeilen
schindet, dass das Programm doppelt so gross wird. In Zeilen gerechnet.
Leerzeilen sind zwar dem Compiler egal, aber irgendwann verliert man den
Überblick allein aufgrund der Länge.
> Noch ein Lob. Ich finde finde Variablenbezeichnung des TE sehr gut.> Ich finde es immer wieder schrecklich z.B. mit Mathematikern zu> arbeiten, die Variablen a la : a ,b, a1 o.ä. verwenden.
Wie oft sind die in der reinen Mathematik selbst mehrstellige Variablen
begegnet? In grauer Vorzeit hatte man mal ohne weise Voraussicht
entschieden, dass "ab" die Multiplikation von "a" und "b" darstellt.
Damit war das Kind im Brunnen und mehrstellige Bezeichner ein Problem.
Dass Programme die Denkweise ihrer Autoren wiederspiegeln kann nicht
verwundern. Mathematiker bevorzugen eben die formale Kürze, statt
COBOL-haftes Geschwafel.
Auch dein "a1" ist ja für den nicht in der IT verhafteten Mathematiker
eher eine tiefgestellte 1, die man bloss nicht genau so in den Computer
kriegt. Statt dessen nimmt der Mathematiker (oder Physiker) lieber
allerlei exotische Zeichen aus fremden Sprachen, oder lässt seine
grafische Phantasie walten. Und wenn man Mathematiker eine
Programmiersprache frei gestalten lässt, dann kommt etwas wie APL dabei
heraus, mitsamt eigenem Zeichensatz und wechselbaren Tastenkappen für
die Tastatur.
Daher sage ich ja auch, dass sich über vielerlei Dinge die Geister
scheiden.
Mir get es nur auf die Nerven, wenn ich dann als wandelnder Debugger
missbraucht werde und dann nen ekeligen Codestyle vorgesetzt bekomme.
Wegen dem lob: Ich habe mir die genaue Bezeichnung nicht angeschaut,
doch bezog ich mich lediglich auf die Tatsache, dass unter anderem
Mathematiker unschöne Bezeichnungen benutzen. Letztendlich sollte man
mit alldem zurechtkommen. Wenn es kleinere Dinge sind, wie es ja hier
häufiger der Fall ist(wo vor allem auch meist nicht mehr als eine Person
dran arbeitet), ist es wichtig, dass man seinen Stil selber gut
versteht.
Wenn man allerdings etwas für die Allgemeinheit präpariert, dann sollte
man schon auf gängige Paradigmen zurückgreifen.