C Programm optimieren und verschönern

[prog234 (Gast)]

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:

{ 
for(markerEssen=0;markerEssen<5;markerEssen++){
for(markerZusaetze=0;markerZusaetze<20;markerZusaetze++){
  
if (einTag[markerTag].fuenfEssen[markerEssen].zusatzstoffe[markerZusaetze]==Zusatzstoff)
{
printf("Bezeichnung des Gerichts:\n %s\n\nDatum des Tags: %i.%i.%i\n\n\n",
einTag[markerTag].fuenfEssen[markerEssen].bezeichnung,einTag[markerTag].datum_des_beispiels[2],
einTag[markerTag].datum_des_beispiels[1],einTag[markerTag].datum_des_beispiels[0]);
}}}
  
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!");}
}

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.ä. :

for(markerEssen=0;markerEssen<5;markerEssen++){&&(markerZusaetze=0;markerZusaetze<20;markerZusaetze++){

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:

....

if(Zusatzstoff!=1&&Zusatzstoff!=2&&Zusatzstoff!=3&&Zusatzstoff!=6&&Zusatzstoff!=9
   &&Zusatzstoff!=11&&Zusatzstoff!=12&&Zusatzstoff!=13&&Zusatzstoff!=19)
  
  else printf("\nEingabe ungültig! Programm wird beendet!");
}

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

[Sebastian V. (sebi_s)]

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:

if(bedingung)
{
  // hier nichts
}
else
{
  printf("\nEingabe ungültig! Programm wird beendet!");
}

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!");
}

PS: Wenn du deine Code aufräumen willst, dann rücke erstmal alles 
passend ein.

[Rufus Τ. F. (rufus)]

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.

for(markerEssen=0;markerEssen<5;markerEssen++){&&(markerZusaetze=0;markerZusaetze<20;markerZusaetze++){

In Kurzform hast Du also geschrieben:

for (a = 0; a < 5; a++) { && (b = 0; b < 20; b++) {

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.

[C-liker (Gast)]

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

[Heini (Gast)]

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.

[Heini (Gast)]

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.

[Daniel A. (daniel-a)]

Rufus Τ. Firefly schrieb:
> so daß
> Du nicht zwei unterschiedlich oft zu durchlaufende Schleifen in einer
> zusammenfassen kannst.

Ach blödsinn, umformen kann man immer!

for(markerEssen=0,markerZusaetze=0;markerZusaetze<20;markerEssen=(++markerEssen<5?markerEssen:(markerZusaetze++,0))){
}

[Rufus Τ. F. (rufus)]

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.

[Daniel A. (daniel-a)]

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 )

[prog234 (Gast)]

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.

[Max H. (hartl192)]

prog234 schrieb:
> Was bedeutet die Verkettung "<5?"

https://de.wikibooks.org/wiki/C-Programmierung:_Ausdr%C3%BCcke_und_Operatoren#Bedingung_.3F:

[prog234 (Gast)]

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. (hartl192)]

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!");

[prog234 (Gast)]

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.

[kaese (Gast)]

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.

[käse^2 (Gast)]

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.

[Joe F. (easylife)]

GeradeAnfängerKönnenVomEinsatzDerSpaceTasteProfitieren.

[Karl H. (kbuchegg)]

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

  if( ! ( Zusatzstoff ==  1 ||
          Zusatzstoff ==  2 ||
          Zusatzstoff ==  3 ||
          Zusatzstoff ==  6 ||
          Zusatzstoff ==  9 ||
          Zusatzstoff == 11 ||
          Zusatzstoff == 12 ||
          Zusatzstoff == 13 ||
          Zusatzstoff == 19 ) )
    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.

[Tom (Gast)]

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.

bool stoff_ist_ok(int zs)
{
   return (zs == 1) || (zs == 2) /* || ...  usw. */;
}

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:

int main(void)
{
   /* ###########################################*/
   /* Testcode */
   /* nur zum pruefen, ob stoff_ist_ok() funktioniert: */
   int zusatz;
   for(zusatz = 0; zusatz < 17; zusatz++)
   {
      printf("Zusatz %d ist ", zusatz);
      if (stoff_ist_ok(zusatz))
         printf("OK\n");
      else
         printf("giftig\n");
   }
   /* Ende Testcode */
   /* ###########################################*/

/* 
Der ganze Rest von main() wird erstmal auskommentiert, bis stoff_ist_ok() das richtige tut.
*/
}

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:

if ( ! stoff_ist_ok(Zusatzstoff) )
{
   printf("Alles falsch, geh weg\n");
   exit(32);
}

Das liest sich fast wie Prosa und man muss an dieser Stelle nicht mehr 
über Details der Zusatzstoffe nachdenken.

[Simon (Gast)]

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:

if(a<b ||
   b<c ||
   sackKartoffeln > sackErdbeeren){ //^^

   //Hier der Code
}

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.

[Simon (Gast)]

Sehe grade das Karl Heinz dies schon erwähnt hat.
Naja wie dem auch sei. Doppelt hält besser ;)

[Halbwelle (Gast)]

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.

int zusatzstoffExistiert(int zusatzstoff)
{
  static int BekannteZusatzstoffe[] = { 1, 2, 3, 6, 9, 11, 12, 13, 19 };
  static int anzahl = sizeof(BekannteZusatzstoffe) / sizeof(BekannteZusatzstoffe[0]);

  for(int i = 0; i < anzahl; ++i)
  {
    if(zusatzstoff == BekannteZusatzstoffe[i]) return 1;
  }
  return 0;
}

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

[(prx) A. K. (prx)]

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

if(a<b ||
   b<c ||
   sackKartoffeln > sackErdbeeren)

diese Variante favorisiere, auch wenn die Editoren oft versuchen, mir 
dabei einen Strich durch die Rechnung zu machen:

if (a < b
 || b < c
 || 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.

[Simon (Gast)]

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.