"goto"-Befehl in C

[Been (Gast)]

Hallo,

ob GOTO-Befehle sinnvoll sind oder nicht möge an dieser Stelle außen vor 
bleiben.

Meine Frage ist:

Wie wendet man den GOTO-Befehl formal in C an (synthax)?

(in meinem C-Buch steht nämlich nullkommanichts darüber)

[Floh (Gast)]

Been schrieb:
> Wie wendet man den GOTO-Befehl formal in C an (synthax)?

Endlos:
  //Endlosschleife :-)
 goto Endlos

> (in meinem C-Buch steht nämlich nullkommanichts darüber)

hat seinen Grund :-)

[Floh (Gast)]

Strichpunkt fehlt :-)

[avr (Gast)]

Hier im Nachschlagewerk:

http://openbook.galileocomputing.de/c_von_a_bis_z/index.htm


http://openbook.galileocomputing.de/c_von_a_bis_z/008_c_kontrollstrukturen_012.htm#mj42701038b17e1c01b0daef016a195d43

avr

[D. I. (Gast)]

Floh schrieb:

>> (in meinem C-Buch steht nämlich nullkommanichts darüber)
>
> hat seinen Grund :-)

auch wenn goto böse ist. in der treiberentwicklung ist es doch ganz nett 
zum aufräumen nach einer fehlerbehandlung, jenachdem an welcher stelle 
der fehler auftritt um sich wildes copy pasting zu sparen.

[Klaus (Gast)]

Been schrieb:
> Wie wendet man den GOTO-Befehl formal in C an (synthax)?

Die Syntax von Syntax ist Syntax  ;-)

[Floh (Gast)]

D. I. schrieb:
> auch wenn goto böse ist. in der treiberentwicklung ist es doch ganz nett
> zum aufräumen nach einer fehlerbehandlung, jenachdem an welcher stelle
> der fehler auftritt um sich wildes copy pasting zu sparen.

ich persönlich würde nicht sagen, das goto böse ist, komm ja selbst eher 
aus der Assemblerecke bei den AVRs.
Finde nur, das goto nicht wirklich ins Sprachkonzept funktionelle 
Programmierung reinpasst, von daher eher unschön :-)

[g457 (Gast)]

Floh schrub:
> Finde nur, das goto nicht wirklich ins Sprachkonzept funktionelle
> Programmierung reinpasst, von daher eher unschön :-)

C ist zwar nicht funktional sondern imperativ, trotzdem kann ich goto 
(in C) nur schwer leiden - es verleitet einen doch allzu leicht zum 
Spaghetticode. Lieber anständigen Code entwickeln, damit kann man 
mindestens 99% aller gotos vermeiden.

[Sven P. (Gast)]

Jo schon, aber im Fall der Fälle einmal zu viel goto vermeidet, dass 
führt zu kilometerlangen If-else-Kaskaden :-)

[Zwölflieter (Gast)]

Eingestreute "break;" in switch() Anweisungen sind kaum anders zu 
bewerten als goto. Trotzdem beschwert sich darüber niemand. Also Mut zum 
goto!

[Dr.Nörgel (Gast)]

Seit über 20 Jahren verdien ich mir meine Kohle mit C-Programmierung, 
ein goto brauchte ich noch nie.

[Peter (Gast)]

Dr.Nörgel schrieb:
> Seit über 20 Jahren verdien ich mir meine Kohle mit C-Programmierung,
> ein goto brauchte ich noch nie.Beitrag melden | Bearbeiten | Löschen |

wie schon oben geschrieben, man kann sich auch ewig mit if - else 
aufhalten nur weil man kein goto verwenden will.

if A=B {
  print("Fehler1");
  goto next;
}

if C=D {
  print("Fehler2");
  goto next;
}

if D=A {
  print("Fehler3");
  goto next;
}

if C=B {
  print("Fehler5");
  goto next;
}

next:

aufräumen();


oder man baut ein while( true ) rings rum und schreibt dann break hin.

aber GOTO gehört zu C, warum sollte man es da nicht verwenden, nur weil 
es einige leute unschön finden.

[D. I. (Gast)]

bzw. so:

a = malloc(...);
if (a == NULL) goto free1;
b = malloc(...);
if (b == NULL) goto free2;
c = malloc(...);
if (c == NULL) goto free3;

//do something

free(c);

free3:
    free(b);
free2:
    free(a);
free1:
    exit(1);

[Been (Gast)]

Floh schrieb:
> Endlos:
>   //Endlosschleife :-)
>  goto Endlos;
Danke, war alles, was ich wissen wollte!
(Semikolon von mir eingefügt)

[Fabian (Gast)]

Peter schrieb:
> if A=B {
>
>   print("Fehler1");
>
>   goto next;
>
> }
>
>
>
> if C=D {
>
>   print("Fehler2");
>
>   goto next;
>
> }
>
>
>
> if D=A {
>
>   print("Fehler3");
>
>   goto next;
>
> }
>
>
>
> if C=B {
>
>   print("Fehler5");
>
>   goto next;
>
> }
>
>
>
> next:
>
>
>
> aufräumen();


Ohne Goto:

for (i = 0; i < 5; i++)
   if (A[i] == A[i+1])
      printf("Fehler%d", i);
aufräumen();

[Fabian (Gast)]

PS: Stimmt in diesem Fall ja nur ungefähr, da man i um 2 inkrementieren 
müsste. Aber mittels Pointer und Arrays lässt sich so'n Code wie oben 
allemal umgehen.

[Heiko (Gast)]

GOTO = BÖSE!

[Klaus W. (mfgkw)]

Wobei man aber auch wissen sollte, daß nicht alle Sprünge mit goto
(sicher) machbar sind.

- man darf von einem Block nach außen springen (vorwärts wie
  rückwärts):

    {
        // ...
        goto fertig; // ok
    }
    ...
  fertig:
    ...
    {
        // ...
        goto fertig; // ok
    }

- man darf NICHT in einen Block springen und dadurch
  Initialisierungen umgehen:

    goto weiter; // umgeht Initialisierung von i, nicht legal
    ...
    {
        int i=0;
        // ...
      weiter:
        printf( "%d", i );
        // ...
    }

- man kann nicht von einer Funktion in eine andere springen

[Klaus W. (mfgkw)]

Heiko schrieb:
> GOTO = BÖSE!

... und böse ist manchmal gut!

[Tim T. (tim_taylor)]

Auch wenns nichts mehr mit der Frage des OP zu tun hat, denke ich das 
beim Wegfall der Goto-Funktion die gesamte C-Codequalität eher steigen 
als sinken würde.
Was das immerwieder vorgeholte Anwendungsbeispiel mit den Fehlercodes 
angeht, so dürfte es durchaus sinnvoll sein die Auswertung in eine 
eigene Funktion zu packen und mit multiplen returns zu arbeiten.
Und ja, ich weis das multiple returns ebenfalls irgendwo 
(Automobilbereich oder so) als böse definiert wurden, jedoch hält sich 
der damit anstellbare Schaden in Grenzen; ich habe viele grauenvolle 
Beispiele mit gotos gesehen aber eigentlich keine mit returns...

[ich (Gast)]

Peter schrieb:
> wie schon oben geschrieben, man kann sich auch ewig mit if - else
> aufhalten nur weil man kein goto verwenden will.
>
> if A=B {
>   print("Fehler1");
>   goto next;
> }
...

Versuchs mal mit:
if A==B

Typischer Anfängerfehler sowas.

[Tim T. (tim_taylor)]

ich schrieb:
> ...
>
> Versuchs mal mit:
> if A==B
>
> Typischer Anfängerfehler sowas.

Und wenn du noch Klammern um die Bedingung machst, interessiert sich 
auch niemand mehr für den Sack Reis der grade in China umgefallen ist...

[ich (Gast)]

Tim T. schrieb:
> ich schrieb:
>> ...
>>
>> Versuchs mal mit:
>> if A==B
>>
>> Typischer Anfängerfehler sowas.
>
> Und wenn du noch Klammern drum machst, interessiert sich auch niemand
> mehr für den Sack Reis der grade in China umgefallen ist...
>

Ein Beispiel mit Fehler kann man nicht einfach unkommentiert stehen 
lassen.

Übrigens ist Reis in China ein hochgeschätztes Grundnahrungsmittel.

[Tim T. (tim_taylor)]

ich schrieb:
> Ein Beispiel mit Fehler kann man nicht einfach unkommentiert stehen
> lassen.
>
> Übrigens ist Reis in China ein hochgeschätztes Grundnahrungsmittel.

Naja, man sollte am besten den Ganzen Thread löschen, die Antwort auf 
die Frage des OP hätte man in einer Minute per Google finden können, 
höchstwahrscheinlich sogar mit einem Treffer der hier ins Forum 
verweist. Alles Andere was hier sonst noch erörtert wurde habe ich 
bereits gefühlte 10 mal hier im Forum gelesen...

[Klaus (Gast)]

ich schrieb:
> Ein Beispiel mit Fehler kann man nicht einfach unkommentiert stehen
> lassen.

Ach was. Und deswegen enthält dein Kommentar also weitere Fehler...

[Sven P. (Gast)]

Tim T. schrieb:
> Auch wenns nichts mehr mit der Frage des OP zu tun hat, denke ich das
> beim Wegfall der Goto-Funktion die gesamte C-Codequalität eher steigen
> als sinken würde.
> Was das immerwieder vorgeholte Anwendungsbeispiel mit den Fehlercodes
> angeht, so dürfte es durchaus sinnvoll sein die Auswertung in eine
> eigene Funktion zu packen und mit multiplen returns zu arbeiten.
Schöner ist das dann aber meistens auch nicht.
Bei dem Beispiel mit den Fehlercodes ging es ja nicht darum, eine 
Meldung anzuzeigen, das war wohl nur stellvertretend. Und alle 
Aufräum-Funktionen auszulagern ist auch oft Käse, weil entweder jede 
Menge doppelter Code entsteht oder es ein Chaos an Parametern gibt.

Viel schlimmer finde ich, wie manche ihren Quelltext mit sinnlosen 
Kommentaren überfluten, die größtenteils aus Zeilen voller ********** 
bestehen. Oder die hunderttausendste Kommentarkonvention anstelle von 
Doxygen oder sowas. Oder miserabel oder mit Leerzeichen eingerückter 
Quelltext.

Da stört mich goto noch am wenigsten.

[Floh (Gast)]

Sven P. schrieb:
> Oder miserabel oder mit Leerzeichen eingerückter
> Quelltext.

Mich stören ehrlich gesagt eher Tabs beim Einrücken. Mal kurz nen 
anderen Editor und mit Pech ist deine ganze Formatierung hinüber.
:-)

[raketenfred (Gast)]

int i=0;
marke:
if(i<max)
{
i++;
/*.....*/
goto marke;
}

einen schönen gruß an die Fußnägel ;-)-Rock'n'Roll

[Bejahn (Gast)]

GOTO ist GEIL!


  ;O)

[Sven P. (Gast)]

Floh schrieb:
> Sven P. schrieb:
>> Oder miserabel oder mit Leerzeichen eingerückter
>> Quelltext.
>
> Mich stören ehrlich gesagt eher Tabs beim Einrücken. Mal kurz nen
> anderen Editor und mit Pech ist deine ganze Formatierung hinüber.
> :-)

Du sollst deshalb ja auch ordentlich einrücken. Und das schließt 
solche Kunstwerke, bei denen der Quelltext an irgendwas bündig 
eingerückt wird, aus. So von wegen

void ein_langer_funktionsname(
                              int a,
                              int b
                             )
{
}

void kurz(
          char x,
          char y
         )
{
}

Das is ne Katastrophe.

[Oliver K. (okraits)]

Überleg's Dir gut ;-)

http://imgs.xkcd.com/comics/goto.png

[Eddy C. (chrisi)]

goto ist harmlos im Vergleich zu throw von C++. Das heisst aber nicht, 
dass ich auf das Eine oder Andere verzichte ;-)

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

Ich plädiere für InterCals "come from".

[Hc Z. (mizch)]

Sven P. schrieb:
> Du sollst deshalb ja auch ordentlich einrücken.

Ja.  Wie das geht, zeigt z.B. http://www.de.ioccc.org/1995/dodsond1.c .

Ein Musterbeispiel, das sicher mit ein paar gotos noch schöner 
hinzubringen wäre.  Was sonst könnte passender sein als es damit 
auszuschmücken?

[milchkakao (Gast)]

Mit "goto" könnte man Krieg anfangen, da wurde die ganze Generation 
gelehrt goto ist böse, das ist einfach krank. Und dann die Tabs, 
Leerzeichen gehören zwischen den Wörtern, Tabs zum einrücken, wer es 
enger mag kann es in seinem Editor ja einstellen.

"Of course, in stupid languages like Pascal, where labels cannot be
descriptive, goto's can be bad. But that's not the fault of the goto,
that's the braindamage of the language designer."
     Linus
Quelle: http://kerneltrap.org/node/553/2131

[Tim T. (tim_taylor)]

Sven P. schrieb:
> Viel schlimmer finde ich, wie manche ihren Quelltext mit sinnlosen
> Kommentaren überfluten, die größtenteils aus Zeilen voller **********
> bestehen. Oder die hunderttausendste Kommentarkonvention anstelle von
> Doxygen oder sowas. Oder miserabel oder mit Leerzeichen eingerückter
> Quelltext.

Da muss ich mich wohl Schuldig bekennen, zumindest was die Leerzeichen 
angeht habe ich seit geraumer Zeit im Editor eingestellt das Tabs durch 
Leerzeichen ersetzt werden, um genau zu sein durch eines pro 
Einrückebene. Die Gründe dafür waren das man sonst einfach zuwenig in 
eine Zeile bekommt sobald man mal ein paar Ebenen tief in einer Funktion 
ist, insbesondere beim Ausdrucken und das der Code eben immer und 
überall gleich aussieht unabhängig von irgendwelchen Tabeinstellungen.

[Sven P. (Gast)]

Tim T. schrieb:
> Da muss ich mich wohl Schuldig bekennen, [...]

Das erkaufst du dir aber nicht grad günstig. Wenn du zu wenig in eine 
Zeile bekommst und tief einrücken musst, stimmt meistens (nicht immer!) 
aber auch schon woanders etwas nicht.

Ich fand das immer ätzend, irgendwann bin ich nur noch am Einrücken. 
Sobald in der Leitzeile was verändert wird, muss man fünf Zeilen drunter 
nachrücken usw.
Auch wird der Text nicht gerade maschinenlesbarer. Das erschwert es, 
z.B. einfach mal mit grep heranzugehen.

[Tim T. (tim_taylor)]

Sven P. schrieb:
> Das erkaufst du dir aber nicht grad günstig. Wenn du zu wenig in eine
> Zeile bekommst und tief einrücken musst, stimmt meistens (nicht immer!)
> aber auch schon woanders etwas nicht.

Ich benutz halt gerne selbsterklärende Variablen und Funktionsnamen, der 
Autovorschlag des Editors machts möglich.

> Ich fand das immer ätzend, irgendwann bin ich nur noch am Einrücken.
> Sobald in der Leitzeile was verändert wird, muss man fünf Zeilen drunter
> nachrücken usw.

Heute geht das automatisch bzw. halbautomatisch indem du einfach den 
Bereich markierst der ein- oder ausgerückt werden soll.

> Auch wird der Text nicht gerade maschinenlesbarer. Das erschwert es,
> z.B. einfach mal mit grep heranzugehen.

Habs lange nicht mehr gebraucht, mir fällt aber akut kein Problem dabei 
ein.

[Sven P. (Gast)]

Aber du merkst ja schon: Du, du, du, du, dein Editor :-)

Was machste denn, wenn du den Quelltext an so schäle Leute wie mich 
weitergeben möchtest? Schriftgröße mindestens 16 Punkte bei 1024x786, 
Tabulatoren 8 Zeichen breit.

Das macht dann nämlich keinen Spaß mehr.
Aber über Geschmack kann man ja streiten.

[D. I. (Gast)]

Sven P. schrieb:
> Aber du merkst ja schon: Du, du, du, du, dein Editor :-)
>
> Was machste denn, wenn du den Quelltext an so schäle Leute wie mich
> weitergeben möchtest? Schriftgröße mindestens 16 Punkte bei 1024x786,
> Tabulatoren 8 Zeichen breit.
>
> Das macht dann nämlich keinen Spaß mehr.
> Aber über Geschmack kann man ja streiten.

Dann würde ich dich bitten im 21. Jahrhundert anzukommen :P

[Tim T. (tim_taylor)]

Sven P. schrieb:
> Aber du merkst ja schon: Du, du, du, du, dein Editor :-)

Ja, ist mir nicht entgangen. ;-)

> Was machste denn, wenn du den Quelltext an so schäle Leute wie mich
> weitergeben möchtest? Schriftgröße mindestens 16 Punkte bei 1024x786,
> Tabulatoren 8 Zeichen breit.

Unter anderem deswegen hab ich keine Tabulatoren drin sondern nur 
Leerzeichen, weil die schälen Leute die ich kenne teilweise nichtmal das 
mit dem Einstellen der Tabweiten hinbekommen, von irgendwelchen Tab -> 
n*Leerzeichen Ersetzungen ganz zu schweigen.

> Das macht dann nämlich keinen Spaß mehr.

Das Benutzen von fremden Quelltexte macht selten Spaß, zumindest wenn 
man noch dran schrauben muss und sie nicht einfach per Header einbinden 
kann.
Hab da immernoch Albträume von einer Steuerung die ich von Bascom nach C 
portiert habe; grausamerweise hab ich später festgestellt das diese 
vorher von C nach Bascom portiert wurde...

> Aber über Geschmack kann man ja streiten.

Durchaus.

[Sven P. (Gast)]

Naja, die Tabulatoren kann ich mir ohne Weiteres umstellen, wie ich sie 
gerne lesen möchte. Geht aber natürlich nicht, wenn im Quelltext schon 
moderne Kunst mit Leerzeichen betrieben wurden -- dann passt nix mehr. 
Deshalb mag ich ja auch solche Einrückungen aufs Zeichen genau nicht, 
das geht dann immer in die Hose.

Aber ich sag da nix dazu :-)

  for ( ;  btw;                  /* Repeat until all data transferred */
    wbuff += wcnt, fp->fptr += wcnt, *bw += wcnt, btw -= wcnt) {
    if ((fp->fptr % 512U) == 0) {        /* On the sector boundary? */
      if (fp->csect >= fp->fs->csize) {    /* On the cluster boundary? */
        if (fp->fptr == 0) {        /* On the top of the file? */
          clust = fp->org_clust;      /* Follow from the origin */
          if (clust == 0)          /* When there is no cluster chain, */
            fp->org_clust = clust = create_chain(0);  /* Create a new cluster chain */
        } else {              /* Middle or end of the file */
          clust = create_chain(fp->curr_clust);      /* Trace or streach cluster chain */
        }
        if (clust == 0) break;        /* Could not allocate a new cluster (disk full) */
        if (clust == 1 || clust >= fp->fs->max_clust) goto fw_error;
        fp->curr_clust = clust;        /* Update current cluster */
        fp->csect = 0;            /* Reset sector address in the cluster */
      }
      sect = clust2sect(fp->curr_clust) + fp->csect;  /* Get current sector */
      cc = btw / 512U;            /* When remaining bytes >= sector size, */
      if (cc) {                /* Write maximum contiguous sectors directly */
        if (fp->csect + cc > fp->fs->csize)  /* Clip at cluster boundary */
          cc = fp->fs->csize - fp->csect;
        if (disk_write(0, wbuff, sect, (BYTE)cc) != RES_OK)
          goto fw_error;
        fp->csect += (BYTE)cc;        /* Next sector address in the cluster */
        wcnt = 512U * cc;          /* Number of bytes transferred */
        continue;
      }
      if (fp->fptr >= fp->fsize) {      /* Flush R/W window without reading if needed */
        if (!move_window(0)) goto fw_error;
        fp->fs->winsect = sect;
      }
      fp->csect++;              /* Next sector address in the cluster */
    }
    sect = clust2sect(fp->curr_clust) + fp->csect - 1;  /* Get current sector */
    if (!move_window(sect)) goto fw_error;    /* Move sector window */
    wcnt = 512U - (fp->fptr % 512U);      /* Put partial sector into sector window */
    if (wcnt > btw) wcnt = btw;
    memcpy(&fp->fs->win[fp->fptr % 512U], wbuff, wcnt);
    fp->fs->winflag = 1;
  }

(FatFs - Tiny FAT file system module  R0.06  (C)ChaN, 2008)

[Klaus W. (mfgkw)]

Eddy Current schrieb:
> goto ist harmlos im Vergleich zu throw von C++.

Alles Firlefanz.
Wirklich kreativ kann man mit longjmp() programmieren.

[Sven P. (Gast)]

Duff's Apparat:

  send(to, from, count)
  register short *to, *from;
  register count;
  {
    register n=(count+7)/8;
    switch(count%8){
    case 0:  do{  *to = *from++;
    case 7:    *to = *from++;
    case 6:    *to = *from++;
    case 5:    *to = *from++;
    case 4:    *to = *from++;
    case 3:    *to = *from++;
    case 2:    *to = *from++;
    case 1:    *to = *from++;
      }while(--n>0);
    }
  }

Ganz ohne goto...

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

Sven P. schrieb:

> Ganz ohne goto...

Ich würd's eher ein "computed goto" nennen. FORTRAN ist da ehrlicher.

[Rolf Magnus (Gast)]

Eddy Current schrieb:
> goto ist harmlos im Vergleich zu throw von C++. Das heisst aber nicht,
> dass ich auf das Eine oder Andere verzichte ;-)

Och, bei C++ ist das dank funktionierendem RAII doch noch richtig gut. 
Viel schlimmer ist es bei Java oder C#.

Sven P. schrieb:
> Du sollst deshalb ja auch ordentlich einrücken. Und das schließt
> solche Kunstwerke, bei denen der Quelltext an irgendwas bündig
> eingerückt wird, aus.

Ich hab nur noch nie gesehen, daß das jemand mit Tabs richtig 
hinbekommen hätte. Am schlimmsten ist Code, wo jemand (konsequent!) eine 
einzelne Einrückung mit vier Spaces und zwei Einrückungen mit einem Tab 
macht. Ich weiß nicht, warum jemand sowass tut, aber ich habe schon 
öfters gesehen.
Mit einer Tab-Weite von 2 macht das den Code mal richtig unlesbar.

Sven P. schrieb:
> Naja, die Tabulatoren kann ich mir ohne Weiteres umstellen, wie ich sie
> gerne lesen möchte. Geht aber natürlich nicht, wenn im Quelltext schon
> moderne Kunst mit Leerzeichen betrieben wurden -- dann passt nix mehr.

Deshalb ist es am einfachsten, ausschließlich Leerzeichen zu verwenden.

A. K. schrieb:
> Sven P. schrieb:
>
>> Ganz ohne goto...
>
> Ich würd's eher ein "computed goto" nennen. FORTRAN ist da ehrlicher.

In GCC gibt's da noch eine Erweiterung für Goto:

http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Labels-as-Values.html#Labels-as-Values

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

Rolf Magnus schrieb:

> einzelne Einrückung mit vier Spaces und zwei Einrückungen mit einem Tab
> macht. Ich weiß nicht, warum jemand sowass tut, aber ich habe schon
> öfters gesehen.

Freundliche Grüsse vom Emacs. Der macht das automatisch.

[Nico22 (Gast)]

Rolf Magnus schrieb:
> Sven P. schrieb:
>> Naja, die Tabulatoren kann ich mir ohne Weiteres umstellen, wie ich sie
>> gerne lesen möchte. Geht aber natürlich nicht, wenn im Quelltext schon
>> moderne Kunst mit Leerzeichen betrieben wurden -- dann passt nix mehr.
>
> Deshalb ist es am einfachsten, ausschließlich Leerzeichen zu verwenden.

Liest du eigentlich, was Sven schreibt? Das ist eben nicht einfacher 
und schon gar nicht besser. Es ist am einfachsten, ausschließlich Tabs 
zu verwenden.

Gruß,
Nico

[Sven P. (Gast)]

Rolf Magnus schrieb:
> Sven P. schrieb:
>> Du sollst deshalb ja auch ordentlich einrücken. Und das schließt
>> solche Kunstwerke, bei denen der Quelltext an irgendwas bündig
>> eingerückt wird, aus.
>
> Ich hab nur noch nie gesehen, daß das jemand mit Tabs richtig
> hinbekommen hätte.

Also ich kriegs hin, ohne Leerzeichen. Natürlich, es zwingt mich immer 
mal wieder, eine Zeile zu überdenken, um sie auch optisch schön 
hinzuschreiben. Aber das ist nicht von Nachteil.

[Rolf Magnus (Gast)]

Nico22 schrieb:
> Rolf Magnus schrieb:
>> Sven P. schrieb:
>>> Naja, die Tabulatoren kann ich mir ohne Weiteres umstellen, wie ich sie
>>> gerne lesen möchte. Geht aber natürlich nicht, wenn im Quelltext schon
>>> moderne Kunst mit Leerzeichen betrieben wurden -- dann passt nix mehr.
>>
>> Deshalb ist es am einfachsten, ausschließlich Leerzeichen zu verwenden.
>
> Liest du eigentlich, was Sven schreibt?

Vielleicht habe ich es falsch verstanden. Ich dachte, ihm ging es darum, 
daß es nicht mehr paßt, wenn jemand Tabs und Spaces falsch kombiniert 
und man es dann nacher mit anderer Tabweite anschaut. Sonst verstehe ich 
das  "dann passt nix mehr" am Schluß seiner Aussage nicht.

> Das ist eben nicht einfacher und schon gar nicht besser.

Doch, denn dann muß man sich keine Gedanken machen, wo man Tabs und wo 
Spaces verwendet. Es paßt einfach so.

> Es ist am einfachsten, ausschließlich Tabs zu verwenden.

Das mag einfach sein, aber gerade dann paßt es überhaupt nicht mehr, 
wenn man es mit anderer Tabweite anschaut als die, mit der es 
geschrieben wurde.

[Sven P. (Gast)]

Es passt schon, man muss sich nur entscheiden, woran man einrückt.
Etwa:

void so_mache_ich_es_nicht(
                           int arg1,
                           int arg2
                          )
{
}

void sondern_so(
<tab>int arg1,
<tab>int arg2
) {


}

Sauber, braucht man nich bei jeder Funktion je nach Länge des Namens 
woanders nach den Parametern zu suchen...

[D. I. (Gast)]

Nur Leerzeichen wäre ja wirklich schön, nur mit Makefiles und 
Python-Skripten wirds dann haarig

[Yalu X. (yalu) (Moderator)]

D. I. schrieb:
> Nur Leerzeichen wäre ja wirklich schön, nur mit Makefiles und
> Python-Skripten wirds dann haarig

Wieso in Python? Python kommt nicht nur problemlos ohne Tabs aus, es
wird sogar von offizieller Stelle davon abgeraten:

  http://www.python.org/dev/peps/pep-0008/

  "For new projects, spaces-only are strongly recommended over tabs.
  Most editors have features that make this easy to do."

Nur bei Make kommt man nicht um den Tab herum, da er dort eine spezielle
syntaktische Bedeutung hat. Die Make-Erfinder haben dafür aber auch
schon oft Haue bekommen. Naja, Make hat ja mittlerweile über 30 Jahre
auf dem Buckel ;-)

[D. I. (Gast)]

mh bei meinen letzten python-schritten ging das ohne tabs noch daneben.

Aber da ich eh hauptsächlich VHDL beschreibe, ist mir der Tab dann doch 
lieber :D

[Stefan B. (stefan)]

Goto darf man verwenden :-)
http://geekandpoke.typepad.com/geekandpoke/2010/08/thats-code.html

[Karl H. (kbuchegg)]

Formulieren wirs so:
Wer nach der 'Synthax' von goto fragen muss, sollte es auf keinen Fall 
verwenden.

[Gerry E. (micky01)]

Karl heinz Buchegger schrieb:
> Formulieren wirs so:
> Wer nach der 'Synthax' von goto fragen muss, sollte es auf keinen Fall
> verwenden.

Genau, das währe gevärlich. :-)

[Sven H. (dsb_sven)]

Jetzt lasst ihr euch aber auf ein echt niedriges Niveau herab...

[Klaus W. (mfgkw)]

sollte man das nicht bei entsprechenden Fragen?

Ich gehe dann mal schnell weg...

[Johnny B. (johnnyb)]

Also ich persönlich fände theoretisch die Verwendung von Tabs 
sinnvoller, da die ja genau fürs Einrücken gedacht sind.
Da jedoch an den meisten Projekten mehr als eine Person arbeitet und 
über die Jahre die unterschiedlichsten Editoren zur Verwendung kommen, 
verwende ich jedoch in der Praxis ausschliesslich Spaces.
Aber eigentlich geht mir die ständige formatiererei in C sowieso total 
auf den Keks! So empfinde ich die Arbeit mit z.B. Visual Studio für PC 
Software diesbezüglich viel angenehmer, wo automatisch eingerückt und 
formatiert wird. Dann sieht der Code ziemlich ähnlich aus, egal wer 
daran gearbeitet hat und man braucht sich auch nicht mehr gross darum zu 
kümmern.
Auf solches Geschnörkel wie z.B. /**************************/ kann ich 
gerne verzichten.
Gibt auch Programmierer die sowas machen um variablen anzukündigen:
/******************** Variables ********************/
Auch ohne diese Zeile sieht ja jeder Idiot, dass nun Variabeln 
deklariert werden...

Goto; naja, gibt sicher Gründe wo man das gut einsetzen kann. Finde es 
jedenfalls nicht übler als ein break in einer for-Schleife oder mehrere 
returns in einer Funktion. Alles gut und sauber solange man weiss was 
man tut, aber wehe wenn nicht...

[Dennis (Gast)]

Herrlich diese Diskussion über Codeformatierung :-)

Aber Code Beautyfier sind den werten Herrschaften doch auch ein Begriff, 
oder? 2 Sekunden Laufzeit, und man hat den Code exakt so, wie man es 
selber auch formatiert hätte...

Alternativ kann man es natürlich auch selber schreiben, ist jetzt auch 
nicht sooo der Aufwand.

[Torx (Gast)]

Immer direkt die Fehler beachten und "pessimistisch programmieren", das 
heisst immer direkt das programmieren was man bei einem Fehler denn 
machen moechte:

#define ERROR1 10
#define ERROR2 20
#define ERROR3 30

a = malloc(...);
if (a == NULL) {
  /* das leben ist doof, nichtmal speicher gibts hier, ich gebe dir ne zehn */
  exit(ERROR1);
}

/* ok, bis hierhin haben wir es geschafft, ab in den naechsten Level :) */

b = malloc(...);
if (b == NULL) {
  /* jetzt gibts ein wenig mehr zu tun, aufraeumen und weg... */
  free(a);
  exit(ERROR2);
}

/* das Schoene ist, wenn man es bis hierhin geschafft hat, sind auf jeden fall schonmal a und b einwandfrei. Auf zum naechsten "Allokation-Abenteuer" */

c = malloc(...);
if (c == NULL) {
  free(a);
  free{b);
  exit(ERROR3);
}

//do something

/* gibts ja garnicht, wir sind einwandfrei bis hierhin gekommen. Direkt aufraeumen und mit Errorlevel 0 beenden */

free(c);
free(b);
free(a);

exit(0);

[Rolf Magnus (Gast)]

D. I. schrieb:
> Nur Leerzeichen wäre ja wirklich schön, nur mit Makefiles und
> Python-Skripten wirds dann haarig

Ein guter Editor "weiß", daß bei Makefiles zum Einrücken immer Tabs zu 
verwenden sind und tut das deshalb unabhängig von der sonstigen 
Einstellung.

Heiko schrieb im Beitrag #1853727:
> GOTO = BÖSE
>
> Das ist Fakt und wird sich nicht durch eure Diskussion ändern!

Das einzige, woran sich nie etwas ändern wird, ist, daß nichts so 
bleibt, wie es ist. Außerdem sind Verallgemeinerungen grundsätzlich 
immer böse.

Sven P. schrieb:
> void sondern_so(
> <tab>int arg1,
> <tab>int arg2
> ) {
>
>
> }
>
>
> Sauber, braucht man nich bei jeder Funktion je nach Länge des Namens
> woanders nach den Parametern zu suchen...

Ja, ok, so kommst du um den Teil mit den Spaces rum. Ich finde 
allerdings, daß es mit einer öffnenden Klammer ganz am Ende irgendwie 
gewöhnungsbedürftig aussieht, und wenn die Argumente nicht an den 
Klammern ausgerichtet sind, wirkt das für mich etwas 
auseinandergerissen.
Bei mir sieht das eher so aus:

void ich_schreib_das_eher_so(int arg1,
                             int arg2)
{
    if (blah)
    {
        ein_funktions_aufruf(mit_langen_argumenten,
                             und_davon_auch_noch,
                             mehreren);
    }

    und_noch_code();       // mit einem "in-line"-Kommentar

}

Allgemein gibt es zwei Dinge, die man hier berücksichtigen muß, nämlich 
das Einrücken und das, was ich mal als "Ausrichten" bezeichne. Und hier 
der Code nochmal, mit Markierung, wo man einrücken und wo ausrichten muß 
(woraus auch klar werden sollte, was genau ich damit meine):

void ich_schreib_das_eher_so(int arg1,
<AAAAAAAAAAAAAAAAAAAAAAAAAAA>int arg2)
{
<EE>if (blah)
<EE>{
<EEEEEE>ein_funktions_aufruf(mit_langen_argumenten,
<EEEEEE><AAAAAAAAAAAAAAAAAAA>und_davon_auch_noch,
<EEEEEE><AAAAAAAAAAAAAAAAAAA>mehreren);
<EE>}

<EE>und_noch_code();<AAAAA>// Mit einem "in-line"-Kommentar

}

Wenn man Tabs einsetzt und es nachher wirklich mit verschiedenen 
Tabweiten passen soll, ist es zwingend erforderlich, das Einrücken mit 
Tabs und das Ausrichten mit Spaces zu machen, und das ist genau das, was 
in der Praxis meistens in die Hose geht.
Ich hätte abgesehen davon auch ehrlich gesagt keine Lust, für's 
Ausrichten dauernd auf der Space-Taste rumzuhämmern und finde es 
praktisch, sowohl E, als auch A mit der TAB-Taste machen zu können.
Und genau weil das so praktisch ist, wird's auch von vielen 
"Tab-Einrückern" so gemacht...

[Karl H. (kbuchegg)]

Rolf Magnus schrieb:

> Ich hätte abgesehen davon auch ehrlich gesagt keine Lust, für's
> Ausrichten dauernd auf der Space-Taste rumzuhämmern und finde es
> praktisch, sowohl E, als auch A mit der TAB-Taste machen zu können.

Genau darum geht es doch gar nicht.
Jedem Editor, der zum Programmieren eingesetzt wird, kann man per 
Options mitteilen, dass er doch bitte einen Druck auf Tab durch eine 
entsprechende Anzahl Leerzeichen bis zur nächsten Tab Position ersetzen 
soll.

Ob Tab oder nicht Tab ist keine Frage des Komforts beim Editieren 
sondern eine Frage dessen, wie mitfühlend ein Programmierr gegenüber 
seinen Kollegen ist, die seinen Code lesen können sollen.
Ist im das sch...egal, dann lässt er seinen Editor bei einem Druck auf 
Tab auch echte Tabulatoren einsetzen. Mit dem Ergebnis, dass der Code 
nur noch scheisse aussieht, wenn er auf einem Editor mit anderer 
Tab-Weite angezeigt wird.
Ist ihm das nicht egal, dann lässt er seinen Editor Tabs durch 
Leerzeichen ersetzen mit dem Effekt, dass sein Code auf jedem Editor 
genauso aussieht, wie er auch bei ihm im Editor ausgesehen hat.

[nicht Gast (Gast)]

Die Tab-Diskussion ist einfach laecherlich. Genauso, wie man sich als 
"Loesung" auf Einruecken mit n Spaces einigen kann, kann man sich auch 
auf Tabs mit n Zeichen Breite einigen. Ausser, man hat es nicht mit 
Entwicklern, sondern Penaelern zu tun.

[Karl H. (kbuchegg)]

nicht Gast schrieb:
> Die Tab-Diskussion ist einfach laecherlich.

Du hast offenbar noch signifikante Mengen fremden Codes übernehmen 
müssen, bei dem die Tab-Weite nicht zu deiner gepasst hat.

Es ist absolut kein Spass, wenn man erst einmal 2 Tage investieren muss, 
um den Code optisch soweit zu bringen, dass man ihn wieder verstehen 
kann. Für so manchen Fremdcode hab ich dann ein 'untab' Utility in der 
Hinterhand, das ich auf den Code loslasse, und dem ich eine Tab-Weite 
vorgebe (die ich im Editor durch Try&Error ermittelt habe) und welches 
die Tabs durch Spaces ersetzt.
Funktioniert auch gut. Ist nur scheisse bei zugekauften Libraries, durch 
die man mit dem Debugger durchkommen muss (daher in Source Code Form für 
teuer Geld gekauft) und bei jedem Update geht der Schmontz wieder von 
vorne los, nur weil man den Entiwcklern nicht klarmachen kann, dass sie 
nicht davon ausgehen können, dass alle Welt Tabs mit 4 (oder 8) Zeichen 
benutzt.

> Genauso, wie man sich als
> "Loesung" auf Einruecken mit n Spaces einigen kann, kann man sich auch
> auf Tabs mit n Zeichen Breite einigen.

Das ist nicht der springende Punkt.
Den in der Praxis hält es niemand durch, konsequent nur mit Tab 
einzurücken.

[Oliver K. (okraits)]

Zum Glück unterstützen heutzutage die meisten Editoren/IDE's den 
Entwickler beim Formatieren - oder entwickeln manche hier noch mit ed? 
;) Außerdem sollte es in jedem Projekt, an dem mehr als ein Entwickler 
arbeitet, Programmierrichtlinien geben. Die Praxis sieht aber leider 
anders aus.

[Rolf Magnus (Gast)]

Karl heinz Buchegger schrieb:
> Rolf Magnus schrieb:
>
>> Ich hätte abgesehen davon auch ehrlich gesagt keine Lust, für's
>> Ausrichten dauernd auf der Space-Taste rumzuhämmern und finde es
>> praktisch, sowohl E, als auch A mit der TAB-Taste machen zu können.
>
> Genau darum geht es doch gar nicht.
> Jedem Editor, der zum Programmieren eingesetzt wird, kann man per
> Options mitteilen, dass er doch bitte einen Druck auf Tab durch eine
> entsprechende Anzahl Leerzeichen bis zur nächsten Tab Position ersetzen
> soll.

Ähm, ja. Der obige Satz ist ja genau ein Argument dafür, das auch zu 
tun, statt echte Tabs zu verwenden.

> Ob Tab oder nicht Tab ist keine Frage des Komforts beim Editieren
> sondern eine Frage dessen, wie mitfühlend ein Programmierr gegenüber
> seinen Kollegen ist, die seinen Code lesen können sollen.
> Ist im das sch...egal, dann lässt er seinen Editor bei einem Druck auf
> Tab auch echte Tabulatoren einsetzen. Mit dem Ergebnis, dass der Code
> nur noch scheisse aussieht, wenn er auf einem Editor mit anderer
> Tab-Weite angezeigt wird.
> Ist ihm das nicht egal, dann lässt er seinen Editor Tabs durch
> Leerzeichen ersetzen mit dem Effekt, dass sein Code auf jedem Editor
> genauso aussieht, wie er auch bei ihm im Editor ausgesehen hat.

Hmm, hast du meine Abhandlung über die Unterscheidung zwischen Einrücken 
und Ausrichten eigentlich gelesen? Oder gehst du schon a priori nicht 
davon aus, daß das irgendwer macht?

[Karl H. (kbuchegg)]

Rolf Magnus schrieb:

> Hmm, hast du meine Abhandlung über die Unterscheidung zwischen Einrücken
> und Ausrichten eigentlich gelesen?

Hab ich.
Aber anscheinend hab ich nicht verstanden worauf du hinaus willst :-)

[Rolf Magnus (Gast)]

Ok. Mit "Ausrichten" bezeichne ich es, wenn man dafür sorgt, daß bei 
zusammengehörenden Zeilen die Teile auch genau untereinander sind:

    funktionsaufruf(ein_paramenter,
    <--Ausrichten-->noch_ein_parameter);

Es hier also darum, daß der Anfang der Parameternamen genau 
untereinander steht. Das darf man nicht mit Tabs machen, weil sich der 
Funktionsname ja nicht ändert, wenn man eine andere Tab-Weite einstellt.
Wenn man also alles mit Tabs macht, paßt es nicht mit unterschiedlichen 
Tabweiten. Also muß dann das Ausrichten immer noch mit Spaces gemacht 
werden.
Deine Aussage war eigentlich die gleiche, nur daß du gar nicht erst auf 
die Idee gekommen bist, Tabs und Spaces zu kombinieren und deshalb 
gleich zu der Schlußfolgerung kommst, daß es mit Tabs nie paßt. ;-)

[Karl H. (kbuchegg)]

Rolf Magnus schrieb:

> die Idee gekommen bist, Tabs und Spaces zu kombinieren und deshalb
> gleich zu der Schlußfolgerung kommst, daß es mit Tabs nie paßt. ;-)

Weil das eigentlich meine generelle Erfahrung ist.
Egal wie sehr sich der Programmierer bemüht, mit einer anderen Tab-Weite 
kommt praktisch immer ein Kuddelmuddel raus.

Das hier ist zwar theoretisch eine Lösung

<EE>if (blah)
<EE>{
<EEEEEE>ein_funktions_aufruf(mit_langen_argumenten,
<EEEEEE><AAAAAAAAAAAAAAAAAAA>und_davon_auch_noch,
<EEEEEE><AAAAAAAAAAAAAAAAAAA>mehreren);
<EE>}

in der Praxis funktioniert das aber nicht. Zumindest hab ich in all den 
Jahren noch nie Code gesehen, bei dem das tatsächlich 100% durchgezogen 
worden wäre.

[Klaus W. (mfgkw)]

Rolf Magnus schrieb:
> Das darf man nicht mit Tabs machen, weil sich der
> Funktionsname ja nicht ändert, wenn man eine andere Tab-Weite einstellt.

Genau da fängt der Zirkus an:
In der Datei ist nicht hinterlegt, was du unter einer Tab-Weite
vestehst.
Gibst du deinen Text jemandem anderen oder einem Drucker oder einer
anderen IDE, ist die Formatierung für die Katz.

Ich sehe auch keine andere sinnvolle Möglichkeit, als im
Quelltexte keine Tabs zu verwenden, sondern halt stattdessen
Leerzeichen.
Die kosten auch nicht mehr und müssen auch nicht einzeln getippt
werden.
Wozu also Tabs?

[nicht Gast (Gast)]

>> Die Tab-Diskussion ist einfach laecherlich.
>Du hast offenbar noch signifikante Mengen fremden Codes übernehmen
>müssen, bei dem die Tab-Weite nicht zu deiner gepasst hat.

Du weisst offenbar immer genau, wovon andere keine Ahnung haben. Ob 
meine Tab-Weite passt oder nicht, ist voellig irrelevant - da ich die 
Projektvorgabe uebernehme. Fuer Profis gibt es da keine Debatte, nur 
fuer Bastler.

[Morg (Gast)]

>Es ist absolut kein Spass, wenn man erst einmal 2 Tage investieren muss,
>um den Code optisch soweit zu bringen, dass man ihn wieder verstehen
>kann.

>Das ist nicht der springende Punkt.
>Den in der Praxis hält es niemand durch, konsequent nur mit Tab einzurücken.

Dann wuerde ich mir mal ueberlegen, ob ich nicht den Beruf verfehlt 
habe. Primadonna-Entwickler braucht wirklich keiner als Kollege.

[Karl H. (kbuchegg)]

nicht Gast schrieb:
>>> Die Tab-Diskussion ist einfach laecherlich.
>>Du hast offenbar noch signifikante Mengen fremden Codes übernehmen
>>müssen, bei dem die Tab-Weite nicht zu deiner gepasst hat.
>
> Du weisst offenbar immer genau, wovon andere keine Ahnung haben.

Das nicht.
Ich hab aber schon genug fremden Code übernommen und ja durchaus auch 
zugekauften Code, dass ich die Effekte zur Genüge gesehen habe.

Das ist also mehr praktische Anschauung als 'ich weiß es einfach'

> Ob
> meine Tab-Weite passt oder nicht, ist voellig irrelevant - da ich die
> Projektvorgabe uebernehme.

Und ich rede nicht von Code der innerhalb eines Projektteams bleibt. 
Innerhalb eines Projektteams ist die Diskussion müssig.
Problematisch wird es, wenn Code veröffentlicht wird. Problematisch wird 
es, wenn ich mir aus dem Web Code hole. Problematisch wird es wenn ich 
Libraries zukaufe (in Source Form).
Sind wir jetzt auf gleicher Wellenlänge?

> Fuer Profis gibt es da keine Debatte

Genau. Profis haben 'Tabs durch Space ersetzen' eingeschaltet bzw. 
lassen ein untab Tool mit der richtigen Einstellung über den Code 
laufen, ehe sie ihn veröffentlichen. Für einen Profi ist sein Code sein 
Aushängeschild. Da will er auf jeden Fall vermeiden, dass der erste 
Eindruck beim Kunden schon ein schlechter ist. Egal wie der seine Tabs 
eingestellt hat.

[Karl H. (kbuchegg)]

Morg schrieb:
>>Es ist absolut kein Spass, wenn man erst einmal 2 Tage investieren muss,
>>um den Code optisch soweit zu bringen, dass man ihn wieder verstehen
>>kann.
>
>>Das ist nicht der springende Punkt.
>>Den in der Praxis hält es niemand durch, konsequent nur mit Tab einzurücken.
>
> Dann wuerde ich mir mal ueberlegen, ob ich nicht den Beruf verfehlt
> habe. Primadonna-Entwickler braucht wirklich keiner als Kollege.

Das hat mit Primadonna nichts zu tun.
Eher mit der Notwendigkeit seine Tätigkeit auch als Ingenieurstätigkeit 
zu sehen. Und genauso wie in einem Zeichenbüro ein sauber aufgebauter 
und ausgefüllter Zeichnungskopf dazugehört, gehört eine ordentliche 
Formatierung zu SW-Entwicklung. Unabhängig davon welche Editiertools man 
einsetzt. Und zwar auch beim Kunden, wenn dein Kunde selber 
SW-Entwickler ist und bei dir Source Code einkauft.
Alles andere ist Liebhaberei und hat mit professionellem Auftreten 
nichts zu tun. Lass deine 'nur die Funktionalität ist wichtig' 
Sichtweise ruhig bei den Diplomanden an den Unis. Von dort ist man als 
Firma nichts anderes gewohnt, als das man meistens nur Schrott kriegt, 
den ein interner Mitarbeiter erst einmal auf die Minimalstandards 
bringen muss.

[Morg (Gast)]

Nun, du bist hier bekannt genug, so dass jeder weiss, dass du eben nicht 
"beim Kunden entwickelst", sondern im Haus und noch dazu in einer 
Position bist, wo du die Regeln selbst machst. Daher sei entschuldigt, 
dass du keine Ahnung davon hast, was erwartet wird, wenn man "beim 
Kunden" aufschlaegt und dort zu entwickeln hat. Aufgrund meiner 
langjaehrigen Taetigkeit als Freelancer kann ich dir sagen, dass der 
Kunde kein Verstaendnis dafuer hat, dass du erst einmal dein 
Aushaengeschild zurecht rueckst, es dir eine Woche schoen bequem machst 
und allem deinen Stil aufdrueckst. Da ist anpassen und losarbeiten 
angesagt und basta. Erst mal alles umformatieren und wieder einchecken 
statt einfach die Tabbreite umzustellen hat schon Mal einen Kollegen den 
Job gekostet. Der klang eigentlich ganz genauso wie ein paar Leute hier 
und hat auch nicht verstanden, warum das keiner eingesehen hat.

[Karl H. (kbuchegg)]

Morg schrieb:
> Der klang eigentlich ganz genauso wie ein paar Leute hier
> und hat auch nicht verstanden, warum das keiner eingesehen hat.

Du redest von völlig anderen Dingen.

Wenn du in eine Firma kommst, um dort ein paar Monate zu entwicklen, ist 
klar dass dir die Firma ihre Regeln aufs Auge drückt und nicht 
umgekehrt. (Und ja: ich war auch in dieser Situation. Mehr als einmal 
:-)

Das ist nicht das, wovon wir (ich) hier reden!
Wir (Ich zumindest) reden von der Situation, wenn ich es mir aussuchen 
kann. Also keinen Zwang von oben habe.
Und ich rede auch nicht von der Situation, in der ich als Person in eine 
Softwarefirma komme, sondern von der Situation in der Kunde anruft und 
fragt: Hast du für dieses Problem Code fertig und was würde es kosten 
den in Source Form käuflich zu erwerben?

[U.R. Schmitt (Gast)]

Morg schrieb:
> Nun, du bist hier bekannt genug, so dass jeder weiss, dass du eben nicht
> "beim Kunden entwickelst", sondern im Haus und noch dazu in einer
> Position bist, wo du die Regeln selbst machst. Daher sei entschuldigt,
> dass du keine Ahnung davon hast, was erwartet wird, wenn man "beim
> Kunden" aufschlaegt und dort zu entwickeln hat. Aufgrund meiner
> langjaehrigen Taetigkeit als Freelancer kann ich dir sagen, dass der
> Kunde kein Verstaendnis dafuer hat, dass du erst einmal dein
> Aushaengeschild zurecht rueckst, es dir eine Woche schoen bequem machst
> und allem deinen Stil aufdrueckst.

Warum eigentlich so agressiv?
Wenn man beim Kunden für den Kunden entwickelt ist doch klar, daß der 
Kunde entscheidet wie die Regeln sind.

Wenn man aber die freie Wahl hat, dann nutzen 80% der Leute die ich 
kenne keine TABs. Der einzige Grund für Tabs ist mit der Erfindung von 
128 KBit Rams und der Festplatte untergegangen.

[Sven P. (Gast)]

Also seit ich denken kann, rücke ich konsequent mit Tabulatoren ein. Und 
mein Quelltext ist überall lesbar, egal wie breit der Leser seine 
Tabulatoren haben möchte.

Aber ich rücke halt nur ordentlich ein, ausrichten an irgendwelchen 
Grenzen tu ich nicht. Früher wars mir zu viel Arbeit, als die gängigen 
Editoren das noch nicht konnten (nein, EMACS nutze ich nicht). Und heute 
sehe ich einfach keinen Grund dazu. Ich fands beim Lesen schon immer 
furchtbar, wenn Leute nicht in der Lage waren, eine Anweisung ordentlich 
zu formulieren und stattdessen dann ein ellenlanger Wurm entstanden ist, 
der noch über mehrere Zeilen geht und mit Leerzeichen dann notdürftig 
ausgerichtet wurde, damit man ihn überhaupt noch verstehen kann.

Und der Tab hat da m.M.n. zweifellos seine Berechtigung.

[Arc N. (arc)]

Sven P. schrieb:
> Und der Tab hat da m.M.n. zweifellos seine Berechtigung.

Nein. Karl Heinz Buchegger hat da absolut recht.

Beispiele (auch wenn man nicht mit Autoritäten argumentieren sollte):
PHP:
"Use an indent of 4 spaces, with no tabs."
http://pear.php.net/manual/en/standards.indenting.php
Python:
"The most popular way of indenting Python is with spaces only."
http://www.python.org/dev/peps/pep-0008/
Ruby:
"Furthermore, never use tabs, which includes the practice of mixing tabs 
with spaces"
http://www.caliban.org/ruby/rubyguide.shtml
EMACS:
"Tabs Are Evil"
http://www.emacswiki.org/emacs/TabsAreEvil
C:
"No tabs since they give the code always a different look depending on 
the tab settings of the original coder."
http://root.cern.ch/drupal/content/c-coding-conventions
"Tab characters are not used."
http://httpd.apache.org/dev/styleguide.html
"No tabs. No whitespace at the end of a line." "Two spaces per logic 
level."
https://developer.mozilla.org/En/Mozilla_Coding_Style_Guide
.NET:
"Tab characters (\0x09) should not be used in code."
http://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx
F#:
"When indentation is required, you must use spaces, not tabs."

Benutzt habe ich echte Tabs auch nur dann, wenn es irgendjemand 
unbedingt so haben wollte.

p.s. jeder halbwegs brauchbare Editor kann den Code nach belieben 
(um-)formatieren (ob nun geschweifte Klammern in die nächste Zeile 
kommen, diese eingerückt sein sollen, ob hinter einer runden Klammer ein 
Leerzeichen stehen soll oder wo und wie eine Parameterliste umgebrochen 
werden soll etc. pp)

[Sven P. (Gast)]

Und wo ist das Problem?
Tabs sind immer nur dann böse, wenn Leute irgendwelchen Hirnkrampf an 
Ausrichterei versuchen. Mein Gott, auf der einen Seite ist Speicherplatz 
egal und man nimmt Leerzeichen und auf der andren Seite geizt man dann 
mit Zeilen und quetscht.
Das ist dann auch der einzige Grund, an dem sich alle aufhängen.

Lass doch die Klammern in eigenen Zeilen stehen.

int
eine_funktion(
    int argument1,
    char argument2,
    T argument3
)
{


}

Das ist überall einheitlich, unabhängig von den Längen von Bezeichnern 
oder sonstigem Firlefanz. Und es ist immer ordentlich eingerückt, egal 
wie breit Tabulatoren sind.

[Lehrmann M. (ubimbo)]

Das GOTO ist des C Programmierer's Tod. R.I.P

[Yalu X. (yalu) (Moderator)]

Ah, der Threadstarter wollte keinen Goto-Religionskrieg, deswegen
bekommt er jetzt einen Tab-Religionskrieg, grins.

Ok, nachdem der Krieg nun einmal ausgebrochen ist:

Ich finde, eine Textdatei, die unterschiedliche, aber für den Leser
nicht unterscheidbare Zeichen enthält, ist keine Text-, sondern eine
Binärdatei. In Textdateien sollte deswegen von den beiden ASCII-Zeichen
HT (Tab) und SP (Leerzeichen) eins abgeschafft werden. Da der Tab nicht
in jedem Kontext sinnvoll das Leerzeichen ersetzen kann, muss er das
Feld räumen.

Das Hauptargument der Tab-Verfechter, dass damit jeder die Einrückungs-
breite nach seinem Geschmack einstellen kann, ist recht schlaff:

Die Einrückungsbreite ist nur einer von sehr vielen Parametern bei der
Quellcodeformatierung. Für alle anderen (bspw. den Abstand zwischen
Variablennamen und Operatorsymbolen) sind auch keine Steuerzeichen
definiert, über die man den Parameter steuern kann.

Außerdem macht eine ungewohnte Einrückungsbreite den Code ja nicht
unlesbar, solange sie sich in einem halbwegs humanen Bereich von etwa 2
bis 6 Zeichen bewegt. Unlesbar wird der Code erst dann, wenn mehrere
Programmierer an der Erstellung einer Datei beteiligt sind, von denen
die einen Leerzeichen und die anderen Tabs verwenden, was auf Grund der
schweren Unterscheidbarkeit in der Praxis sehr oft passiert.

Deswegen: Ab in die Tonne mit den Tabs. Die Formfeeds und Backspaces
haben den Weg dorthin aus ähnlichen Gründen schon länger geschafft :)

[Sven P. (Gast)]

Hihi :-D

Naja, hier sind Tabs optisch von Leerzeichen zu unterscheiden (Kwrite).

Wie ist denn das, wenn ihr so mit Leerzeichen einrückt:

int bla(int a,
        int b,
        int c);

if (bedingung && (unterbedingung |
                  u2 |
                  zz_top)
   ) /* wie auch immer */

Und jetzt wird 'bla' in 'bummsfallera' umbenannt -- rücken die tollen 
Editoren dann die folgenden Zeilen auch automatisch mit hinterher? Woran 
erkennen sie, dass es eine Fortsetzung ist?

[Rolf Magnus (Gast)]

Sven P. schrieb:
> Und jetzt wird 'bla' in 'bummsfallera' umbenannt -- rücken die tollen
> Editoren dann die folgenden Zeilen auch automatisch mit hinterher?

Macht meiner nicht, aber vorstellbar wär's.
Bei mir kommt es aber eh nur ab und zu mal vor, daß eine Funktion 
umbenannt wird. Noch seltener ist, daß gerade diese dann zufällig auch 
noch so viele Parameter hat, daß ich die Parameterliste umbreche.
Wenn das tatsächlich mal vorkommt, mache ich mir halt mal die Mühe, ein 
paar Leerzeichen von Hand einzufügen.

> Woran erkennen sie, dass es eine Fortsetzung ist?

Z.B. an den Klammern, so wie du und der Compiler das auch tun.

[Karl H. (kbuchegg)]

Rolf Magnus schrieb:

>> Woran erkennen sie, dass es eine Fortsetzung ist?
>
> Z.B. an den Klammern, so wie du und der Compiler das auch tun.


Wobei dei interessante Frage dann auch ist, was macht der PrettyPrint 
mit Kommentaren

if (bedingung && (unterbedingung |
                  u2 |                // was bedeutet u2?
                  zz_top)             // und dann würden wir gerne auch
   )                                  // noch wissen wieso zz_top
                                      // hier auch noch interessant ist

(ich habe den Kommentar absichtlich in eine leere Zeile unter die 
Bedingung verlängert)

[Μαtthias W. (matthias)]

Sven P. schrieb:
> Hihi :-D
>
> Naja, hier sind Tabs optisch von Leerzeichen zu unterscheiden (Kwrite).
>
> Wie ist denn das, wenn ihr so mit Leerzeichen einrückt:
>

> int bla(int a,
>         int b,
>         int c);
>

>
> Und jetzt wird 'bla' in 'bummsfallera' umbenannt -- rücken die tollen

Meiner nicht. Aber um die Einrückung zu korrigieren brauch ich exakt 
fünf Tastanschläge (Alt+Shift -> Pfeil Runter -> Tab -> Tab) wobei Tab 
vier Leerzeichen einfügt.

Tabs gehören wirklich abgeschafft. Linux-Quelltext? Begrenzung auf 80 
Zeichen Zeilenlänge und dann noch eine Tabweite von 8. Das macht mir 
keinen Spaß.

Oder arbeite mal gleichzeitig mit zwei Projekten die einmal mit 8 und 
einmal mit 4 breiten Tabs entstanden sind. Irgendein Quelltext sieht 
dann immer irgendwie kaputt aus. Insbesondere was die Kommentare am Ende 
von Zeilen angeht. Sind die nämlich auch mit Tabs ausgerichtet wirds 
wild.

Matthias, der früher auch mal ein Verfechter von Tabs zum Einrücken war.

[gähnende Leere (Gast)]

nochmal zum Ursprung:
Gibt es eine Sequenz, die ich mit "goto" eleganter lösen kann, als ohne?
Mir fällt einfach nichts ein.

[AS (Gast)]

gähnende Leere schrieb:
> Gibt es eine Sequenz, die ich mit "goto" eleganter lösen kann, als ohne?

Wurde "goto" nicht ursprünglich als Pendant zu "continue" und "break"
in die C Syntax aufgenommen?
Gleiche Iteration bei Rücksprung zum Anfang der Schleife.

Oder anders, frei aus der Hüfte geschossen:

for(...)
{
  ...
  for(...)
  {
    ...
    for(...)
    {
      ...
      if mist()
        goto doofgelaufen;
    }
  }
}
doofgelaufen:

Nein, ich finds auch Kacke ;)

[Rolf Magnus (Gast)]

Findest du die Alternative besser?

bool ausbrechen = false;
for(...)
{
    ...
    for(...)
    {
        ...
        for(...)
        {
            ...
            if mist()
            {
                ausbrechen = true;
                break;
            }
        }
        if (ausbrechen)
            break;
    }
    if (ausbrechen)
        break;
}

Ich jedenfalls nicht.

gähnende Leere schrieb:
> Gibt es eine Sequenz, die ich mit "goto" eleganter lösen kann, als ohne?

Also die beiden, die ich kenne, wurden schon genannt. Das eine ist das 
obige Beispiel mit dem kompletten Abbrechen einer verschachtelten 
Schleife aus der innersten Ebene heraus.
Das zweite ist so grob die unter 
Beitrag "Re: "goto"-Befehl in C" beschriebene 
Fehlerbehandlung.

[Sven H. (dsb_sven)]

Das letzte Beispiel finde ich cool.

[U.R. Schmitt (Gast)]

Ein weiteres Beispiel ist reines C, das keine Exceptions kennt.
Wenn ich einen linearen Ablauf habe in dem ich mehrere API Aufrufe 
benutze, dann kann ich mit goto relativ elegant zu einem definierten 
Fehlerausgang der Funktion springen.
Die Alternative ist ein ständiges

if (!error) {
  error = tue dies
}
if (!error) {
  tue das
}
....

was auch nicht wirklich prickelnd ist
Oder ein Return direkt dann wenn der Fehler passiert. Aber auch das ist 
nicht unbedingt perfekt, denn dann habe nicht ein ddefiniertes return in 
der Funktion, sondern 4, 5 oder noch mehr. Viel Spass beim 
Implementieren eines Trace oder dem setzen eines Breakpoints bevor die 
Funktion verlassen wird.

Insofern goto verdammen macht nicht viel Sinn, man sollte eben versuchen 
sein Hirn einzuschalten bei dem was man tut.

Gruß und Spass

[Vlad T. (vlad_tepesch)]

Solche Regeln sind sowieso nur für physiker, mathematiker, e-techniker 
und Anfänger, da der Code, den die sonst produzieren würden noch 
grottiger wär.

Informatiker brauchen sich daran nicht halten, die könnens sowiso besser 
;)


PS: nicht so ernst gemeint.

[Karl H. (kbuchegg)]

Vlad Tepesch schrieb:

> PS: nicht so ernst gemeint.

Ganz so unrecht hast du nicht.
Da steckt schon ein wahrer Kern dahinter. Nur würde ich Informatikern 
nicht einfach generell einen Persilschein ausstellen wollen.

[Klaus W. (mfgkw)]

> ...physiker, mathematiker, e-techniker...

Puh, an mir als Maschinenbauer ist es ja nochmal knapp vorbei gegangen.
Dann darf ich goto ja noch verwenden, wenn ich es für richtig halte.

[Kuh (Gast)]

 ________________
< GOTO ist BÖSE >
 ----------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||