Die verpönten goto´s

earli

schpätli schrieb:

earli schrieb:

Kurze Faustregel:
Goto nach vorn ist okay (wenn keine Alternative einfacher ist), goto zurück ist böse.

Goto ist dann OK, wenn es die Lesbarkeit des Codes verbessert, oder zumindest nicht verschlechtert.

Deine Regel lässt sich einfach hinschreiben, aber überhaupt nicht umsetzen.

Toller Satz: "Goto ist dann lesbarer, wenn es den Code lesbarer macht."
> http://xkcd.com/703/

volkard

earli schrieb:

schpätli schrieb:

earli schrieb:

Kurze Faustregel:
Goto nach vorn ist okay (wenn keine Alternative einfacher ist), goto zurück ist böse.

Goto ist dann OK, wenn es die Lesbarkeit des Codes verbessert, oder zumindest nicht verschlechtert.

Deine Regel lässt sich einfach hinschreiben, aber überhaupt nicht umsetzen.

Toller Satz: "Goto ist dann lesbarer, wenn es den Code lesbarer macht."
> http://xkcd.com/703/

Ist nur Deine eigene Regel (Goto rückwärts ist eh indiskutablel):
"Goto ist okay, wenn keine Alternative einfacher ist."

earli schrieb:

Toller Satz: "Goto ist dann lesbarer, wenn es den Code lesbarer macht."
> http://xkcd.com/703/

Ich habe das nicht geschrieben?

Lesbarkeit: | Schlecher | Gleich | Besser
------------------------------------------
Goto OK?:   |   Nein    |  Ja    |  Ja

Komplexität: | Höher | Gleich | Geringer
----------------------------------------
Goto OK?:    | Nein  |  Nein  |  Ja

while(1){
  status = recv(new_socket_fd, msg, sizeof(msg),0 );
  if(status > 0){
    readPtr(msg,status);
    continue;
  }else if( status == 0){
  }else{
    //status < 0
  }
  break;
}

loop:
  status = recv(new_socket_fd, msg, sizeof(msg),0 );
  if(status > 0){
    readPtr(msg,status);
    goto loop;
  }else if( status == 0){
  }else{
    //status < 0
  }

bedeutet für mich 18,2% bzw. 12,5% weniger Einkommen nach dem klassischen Cocomo Model, eigentlich habt ihr ja Recht, man soll sich nicht selbst ins Knie schießen

lg lolo

do{
  status = recv(new_socket_fd, msg, sizeof(msg),0 );
  if(status > 0){
    readPtr(msg,status);
  }else if( status == 0){
  }else{
    //status < 0
  }
}while(status > 0);

sowas lässt den vorteil der goto variante verschwinden, man müßte mal testen, ob der compiler die while condition verschwinden lässt, wenn ja könnt ich mich damit schon anfreunden

knivil

aber das goto ist in dem Fall ganz in Ordnung ... manchmal ist ein goto zwingend oder die beste Wahl ... Goto nach vorn ist okay ... Goto ist okay, wenn keine Alternative einfacher ist.

Ich habe noch nie ein goto fuer noetig gehalten. Es gab immer eine bessere Alternative.

Damit wurde in früheren Zeiten schrecklicher Spaghetti-Code erzeugt.

Um Spaghetti-Code zu erzeugen, braucht es kein goto. Lambda, the ultimate GOTO

Die Frage ist nicht, ob gotos in diesem Fall in Ordnung sind, sondern ob der dargestellte Code eher an Spaghettis erinnert. Das tut er. Vorschlaege fuer Verbesserungen wurden bereits gemacht.

rüdiger

knivil schrieb:

aber das goto ist in dem Fall ganz in Ordnung ... manchmal ist ein goto zwingend oder die beste Wahl ... Goto nach vorn ist okay ... Goto ist okay, wenn keine Alternative einfacher ist.

Ich habe noch nie ein goto fuer noetig gehalten. Es gab immer eine bessere Alternative.

Bei der Fehlerbehandlung sind die in C oft praktisch

void foo() {
  allocateX();
  allocateY();

  if(!a())
    goto cleanup;

  if(!b())
    goto cleanup;

  c();

cleanup:
  freeX();
  freeY();
}

FlashBurn

Genau für solche Fehlerbehandlung, wo Code doppelt und dreifach vorhanden ist, nutze ich auch die goto´s!

earli

schpätli schrieb:

earli schrieb:

Toller Satz: "Goto ist dann lesbarer, wenn es den Code lesbarer macht."
> http://xkcd.com/703/

Ich habe das nicht geschrieben?
Lesbarkeit: | Schlecher | Gleich | Besser
------------------------------------------
Goto OK?:   |   Nein    |  Ja    |  Ja
Komplexität: | Höher | Gleich | Geringer
----------------------------------------
Goto OK?:    | Nein  |  Nein  |  Ja

Mein Punkt ist, dass man beides nicht messen kann. Meine Regel sollte ja auch nur eine "Faustregel" sein. Und als solche ist sie klar anwendbar.

earli schrieb:

Mein Punkt ist, dass man beides nicht messen kann.

Eine Abschätzung reicht.

earli schrieb:

Meine Regel sollte ja auch nur eine "Faustregel" sein. Und als solche ist sie klar anwendbar.

Mit Deiner Regel kannst Du Dir den Hintern abwischen.

earli

rüdiger schrieb:

knivil schrieb:

aber das goto ist in dem Fall ganz in Ordnung ... manchmal ist ein goto zwingend oder die beste Wahl ... Goto nach vorn ist okay ... Goto ist okay, wenn keine Alternative einfacher ist.

Ich habe noch nie ein goto fuer noetig gehalten. Es gab immer eine bessere Alternative.

Bei der Fehlerbehandlung sind die in C oft praktisch
void foo() {
  allocateX();
  allocateY();

  if(!a())
    goto cleanup;

  if(!b())
    goto cleanup;

  c();

cleanup:
  freeX();
  freeY();
}

Kein gutes Beispiel, da einfacher:

void foo() {
  allocateX();
  allocateY();

  if(a() && b())
    c();

  freeX();
  freeY();
}

earli

schpätli schrieb:

earli schrieb:

Mein Punkt ist, dass man beides nicht messen kann.

Eine Abschätzung reicht.

Das ist doch gar nicht das Problem. Lesbarkeit ist einfach sehr subjektiv. Und wenn in einer großen Gruppe von Programmierern (zum Beispiel bei Linux -- wo goto unabdingbar ist, da ständig viele Locks auf Ressourcen angelegt und aufgehoben werden -- kamen Patches von über 2000 Personen im Jahr 2009) keine klare Regel angibst, hast du einfach verkackt.

earli schrieb:

Kein gutes Beispiel, da einfacher:

void foo() 
{
  allocateX();
  allocateY();

  if(a() && b())
    c();

  freeX();
  freeY();
}

void foo (void)  // hier gehört "void" in die Klammer
{
  allocateX();
  allocateY();

  if (...)
  {
     for(...)
     {
        while (...)
        {
            do(...)
            {
                if (error) goto exit;
            }
        }
     }
  }
  c();

exit:
  freeX();
  freeY();
}

earli schrieb:

Lesbarkeit ist einfach sehr subjektiv.

Eigentlich nicht, das ist wie mit gutem Geschmack, der ist bei vielen gleich und nur wenige unterscheiden sich davon.

Es mag Menschen geben, die empfinden Source http://www.de.ioccc.org/years.html dieses Types als leserlich, aber der Prozentsatz ist doch relativ klein

earli

noobLolo schrieb:

earli schrieb:

Lesbarkeit ist einfach sehr subjektiv.

Eigentlich nicht, das ist wie mit gutem Geschmack, der ist bei vielen gleich und nur wenige unterscheiden sich davon.

Es mag Menschen geben, die empfinden Source http://www.de.ioccc.org/years.html dieses Types als leserlich, aber der Prozentsatz ist doch relativ klein

Es gibt trotzdem verschiedene Lager, z.B.

- http://en.wikipedia.org/wiki/GNU_Coding_Standards
- http://en.wikipedia.org/wiki/Hungarian_notation
- http://lxr.linux.no/#linux+v2.6.32/Documentation/CodingStyle
- http://blogs.msdn.com/brada/articles/361363.aspx

earli schrieb:

Es gibt trotzdem verschiedene Lager, z.B.

Ja da hast du natürlich Recht, allerdings find ich 4-5 große verschiedene Formatierungen bei xTausend Programmierern eigentlich recht wenig, aber darauf wollt ich nicht hinaus, wir können ja mal über Code von gerstern abstimmen,

von mir

lolo_matrix matrixMultiply(lolo_matrix a,lolo_matrix b){
    lolo_matrix c;
    int l,ll,lll,cache;
    int *aa,*bb,*cc,*bDataCache = b.data,*cDataCache;
    c.cols = a.rows;
    c.rows = b.cols;
    c.data = malloc(sizeof(*c.data)*c.cols*c.rows);

    if(c.data){
        cDataCache = c.data;
        lll = a.rows;
        while(lll--){
            ll = a.cols;
            while(ll--){
                l = c.cols;
                cc = c.data-1;
                aa = a.data++;
                bb = b.data;
                b.data+=b.cols;
                cache = *aa;
                while(l--){
                    *++cc += cache * *bb++;
                }
            }
            b.data = bDataCache;
            c.data += c.cols;
        }
        c.data = cDataCache;
    }
    return c;
}

von Big Brother

// E = A * B
void multiplikation ( Matrix* E, Matrix* A, Matrix* B ) {
    unsigned s, z, k;
    assert ( A->s == B->z );
    for ( z = 0; z < A->z; z++ )
        for ( s = 0; s < B->s; s++ )
            for ( k = 0; k<A->s; k++ )
                    E->m[z*E->s+s] += A->m[z*A->s+k] * B->m[k*B->s+s];
}

Ich denke wir müssen uns nicht darüber unterhalten was schöner ist oder?

earli

Also mir gefällt der Code von Big Brother besser, aber der Style von noobLolo (diese ganzen Leerzeichen bei den Klammern von Big Brother kann ich gar nicht leiden :D).

Nachtrag: Die Sternchen gehören bei mir auch an die Variablen.

So sähe das bei mir eher aus:

/*
 *  E = A * B
 */
void multiplikation(Matrix *E, Matrix *A, Matrix *B) {
    unsigned s, z, k;
    assert(A->s == B->z);
    for (z = 0; z < A->z; z++)
        for (s = 0; s < B->s; s++)
            for (k = 0; k<A->s; k++)
                    E->m[z*E->s+s] += A->m[z*A->s+k] * B->m[k*B->s+s];
}

earli schrieb:

Also mir gefällt der Code von Big Brother besser, aber der Style von noobLolo (diese ganzen Leerzeichen bei den Klammern von Big Brother kann ich gar nicht leiden :D).

Ja, als ich den Code von Big Brother gesehen hab, mußte ich natürlich auch eingestehen das er viel schneller erfaßbar ist. Und da sind wir sicher nicht die einzigen, sondern 99.9% werden so denken.

0.1% war ich, denn ich hab ja den anderen gebastelt, mit der Intention die 2 Multiplikationen für die 2. Dimension zu vermeiden, aber als ich dann den compiler auf -O3 gestellt hab waren die wieder drin

earli

[quote="noobLolo"]

earli schrieb:

0.1% war ich, denn ich hab ja den anderen gebastelt, mit der Intention die 2 Multiplikationen für die 2. Dimension zu vermeiden, aber als ich dann den compiler auf -O3 gestellt hab waren die wieder drin

Das ist auch mal ganz grober Unfug. Multiplikationen sind Kinderkacke, wenn du in jedem Durchlauf zig Pointer dereferenzierst.

earli schrieb:

Multiplikationen sind Kinderkacke

Kinderkacke macht meine cpu mit einem Takt, Multiplikationen nicht