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 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.
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 :-)
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.
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.
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.
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):
1
{
2
// ...
3
gotofertig;// ok
4
}
5
...
6
fertig:
7
...
8
{
9
// ...
10
gotofertig;// ok
11
}
- man darf NICHT in einen Block springen und dadurch
Initialisierungen umgehen:
1
gotoweiter;// umgeht Initialisierung von i, nicht legal
2
...
3
{
4
inti=0;
5
// ...
6
weiter:
7
printf("%d",i);
8
// ...
9
}
- man kann nicht von einer Funktion in eine andere springen
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...
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.
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...
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.
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...
ich schrieb:> Ein Beispiel mit Fehler kann man nicht einfach unkommentiert stehen> lassen.
Ach was. Und deswegen enthält dein Kommentar also weitere Fehler...
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.
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.
:-)
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
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?
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
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.
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.
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.
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.
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
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.
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 :-)
1
for(;btw;/* Repeat until all data transferred */
2
wbuff+=wcnt,fp->fptr+=wcnt,*bw+=wcnt,btw-=wcnt){
3
if((fp->fptr%512U)==0){/* On the sector boundary? */
4
if(fp->csect>=fp->fs->csize){/* On the cluster boundary? */
5
if(fp->fptr==0){/* On the top of the file? */
6
clust=fp->org_clust;/* Follow from the origin */
7
if(clust==0)/* When there is no cluster chain, */
8
fp->org_clust=clust=create_chain(0);/* Create a new cluster chain */
9
}else{/* Middle or end of the file */
10
clust=create_chain(fp->curr_clust);/* Trace or streach cluster chain */
11
}
12
if(clust==0)break;/* Could not allocate a new cluster (disk full) */
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
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.
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
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.
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.
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 ;-)
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
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. :-)
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...
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.
Immer direkt die Fehler beachten und "pessimistisch programmieren", das
heisst immer direkt das programmieren was man bei einem Fehler denn
machen moechte:
1
#define ERROR1 10
2
#define ERROR2 20
3
#define ERROR3 30
4
5
a=malloc(...);
6
if(a==NULL){
7
/* das leben ist doof, nichtmal speicher gibts hier, ich gebe dir ne zehn */
8
exit(ERROR1);
9
}
10
11
/* ok, bis hierhin haben wir es geschafft, ab in den naechsten Level :) */
12
13
b=malloc(...);
14
if(b==NULL){
15
/* jetzt gibts ein wenig mehr zu tun, aufraeumen und weg... */
16
free(a);
17
exit(ERROR2);
18
}
19
20
/* das Schoene ist, wenn man es bis hierhin geschafft hat, sind auf jeden fall schonmal a und b einwandfrei. Auf zum naechsten "Allokation-Abenteuer" */
21
22
c=malloc(...);
23
if(c==NULL){
24
free(a);
25
free{b);
26
exit(ERROR3);
27
}
28
29
//do something
30
31
/* gibts ja garnicht, wir sind einwandfrei bis hierhin gekommen. Direkt aufraeumen und mit Errorlevel 0 beenden */
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:
1
voidich_schreib_das_eher_so(intarg1,
2
intarg2)
3
{
4
if(blah)
5
{
6
ein_funktions_aufruf(mit_langen_argumenten,
7
und_davon_auch_noch,
8
mehreren);
9
}
10
11
und_noch_code();// mit einem "in-line"-Kommentar
12
13
}
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):
<EE>und_noch_code();<AAAAA>// Mit einem "in-line"-Kommentar
12
13
}
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...
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.
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.
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.
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.
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?
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 :-)
Ok. Mit "Ausrichten" bezeichne ich es, wenn man dafür sorgt, daß bei
zusammengehörenden Zeilen die Teile auch genau untereinander sind:
1
funktionsaufruf(ein_paramenter,
2
<--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. ;-)
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
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.
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?
>> 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.
>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.
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.
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.
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.
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?
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.
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.
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.
1
int
2
eine_funktion(
3
intargument1,
4
charargument2,
5
Targument3
6
)
7
{
8
9
10
}
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.
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 :)
Hihi :-D
Naja, hier sind Tabs optisch von Leerzeichen zu unterscheiden (Kwrite).
Wie ist denn das, wenn ihr so mit Leerzeichen einrückt:
1
intbla(inta,
2
intb,
3
intc);
4
5
if(bedingung&&(unterbedingung|
6
u2|
7
zz_top)
8
)/* 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?
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.
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
1
if(bedingung&&(unterbedingung|
2
u2|// was bedeutet u2?
3
zz_top)// und dann würden wir gerne auch
4
)// noch wissen wieso zz_top
5
// hier auch noch interessant ist
(ich habe den Kommentar absichtlich in eine leere Zeile unter die
Bedingung verlängert)
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:>
1
>intbla(inta,
2
>intb,
3
>intc);
4
>
>> 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 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:
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.
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
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.
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.
> ...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.