Werden bei euch Kommentare gemacht?
-
Artchi schrieb:
Auf Kommentare kann man verzichten.
ok, dann mal ein beispiel. was schätzt du, macht diese funktion (alle kommentare entfernt)
void PPR_TX_Machine (void) { switch (PPR_send_status) { case PPR_SEND_IDLE: if (DATA_ACK_NOT_SET) { int f = FIFO_Read (&PPR_send_fifo); if (FIFO_ERROR == f) break; WRITE_DATA_LINES ((UINT8)f); DATA_VALID_ON; PPR_timeout = PPR_GET_COUNTER_VALUE() + 5000; PPR_send_status = PPR_SEND_WAIT_ACK; } break; case PPR_SEND_WAIT_ACK: if (DATA_ACK_SET) { DATA_VALID_OFF; PPR_timeout = PPR_GET_COUNTER_VALUE() + 5000; PPR_send_status = PPR_SEND_WAIT_NOACK; } else if (PPR_timeout < PPR_GET_COUNTER_VALUE()) { DATA_VALID_OFF; PPR_send_status = PPR_SEND_IDLE; } break; case PPR_SEND_WAIT_NOACK: if (DATA_ACK_NOT_SET || (PPR_timeout < PPR_GET_COUNTER_VALUE())) PPR_send_status = PPR_SEND_IDLE; break; } }
-
Ok, war ein bißchen mißverständlich. IM Code sind schon ein paar Kommentare. Es gibt aber kein Dokument über Aufgabe oder Codeaufteilung. Ich habe hier bestimmt an die 100 dsp Projekte und alle gehören zu einem großen Softwareprojekt. Seit Monatg bin ich damit beschäftigt das Ding zu kompilieren. Kompiliere ich A, wird gesagt das typelib X fehlt, welche zu B gehört. B sagt mir das Header Y fehlt. Wenn ich suche finde ich von Header Y 10 verschiedene Versionen, ...
Echt zum Kotzen. Wäre am Besten den ganzen Mist neu zu implemtieren. Stattdessen habe ich eine Liste mit Fehlern die und Änderungswünschen. Shit.@Artchi: Stimme Dir zu, aber wer (außgenommen ein Javafreak) schreibt schon eine Add Funktion
-
Artchi schrieb:
Auf Kommentare kann man verzichten. Gebe aber auch zu, das ein paar Kommentare manchmal nicht schaden können.
Für elemtare Rechenfunktionen mag das stimmen, viel wichtiger wäre hier ein Kommentar, was die Variablen überhaupt darstellen sollen.
-
Mein Favorit:
i++: // i wird um einen erhöht
-
net schrieb:
ok, dann mal ein beispiel. was schätzt du, macht diese funktion (alle kommentare entfernt)
Sie ist bloedsinn. Absolut unlesbar und haengt von globalen variablen ab. also einfach wegschmeissen und neu machen.
und dann auch gleich C++ statt C+ verwenden.
guter Quellcode braucht keine/kaum kommentare und bei schlechtem quellcode reichen 1mio zeilen kommentar nicht aus.
etwas anderes ist natuerlich die doku fuer etwaige anwender, also eine doku fuer eine library - da doxygen zu verwenden ist praktisch. dann hat man schon kommentare im code, aber nur 'schnittstellen kommentare' die oft ueberfluessig sind, aber hier geht es ja um den komfort des anwenders und nicht des programmierers
-
Shade Of Mine schrieb:
Sie ist bloedsinn.
dafür funzt sie aber astrein ohne zicken. du urteilst mal wieder viel zu schnell, shady-baby
Shade Of Mine schrieb:
Absolut unlesbar
ja, schwer lesbar ohne kommentare und ohne die dazugehörige .h-datei zu kennen.
Shade Of Mine schrieb:
und haengt von globalen variablen ab.
die variablen sind 'static' d.h. nur in der datei sichtbar. 4 andere funktionen haben noch zugriff darauf.
Shade Of Mine schrieb:
und dann auch gleich C++ statt C+ verwenden.
geht nicht. gibt keinen c++ compiler für den prozessor wo das läuft
-
net schrieb:
dafür funzt sie aber astrein ohne zicken. du urteilst mal wieder viel zu schnell, shady-baby
korrektheit reicht aber nicht, wenn sie nicht wartbar ist (was sie definitiv nicht ist (allein diese makros...)) wird sie irgendwann mal einen fehler beinhalten der nicht reparierbar oder nur mit grossem aufwand reparierbar ist.
Shade Of Mine schrieb:
ja, schwer lesbar ohne kommentare und ohne die dazugehörige .h-datei zu kennen.
Guten code kann man ohne kommentare lesen. den code kannst du soviel kommentieren wie du willst, er ist mies.
Shade Of Mine schrieb:
die variablen sind 'static' d.h. nur in der datei sichtbar. 4 andere funktionen haben noch zugriff darauf.
ah, wie gut dass das keine globalen variablen sind...
Shade Of Mine schrieb:
geht nicht. gibt keinen c++ compiler für den prozessor wo das läuft
ok, dann kann man auch schoenes C als ersetz nehmen.
anfangen wuerde ich mit schoenen namen und dann die makros etwas kuerzen. schon haetten wir etwas lesbareres.
PS:
such lieber mal nach ein paar threads zu diesem thema, das wurde schon oft genug gesagt, dass guter code keine kommentare braucht und unnoetige kommentare den lesefluss stoeren.
-
net schrieb:
Artchi schrieb:
Auf Kommentare kann man verzichten.
ok, dann mal ein beispiel. was schätzt du, macht diese funktion (alle kommentare entfernt)
void PPR_TX_Machine (void) { switch (PPR_send_status) { case PPR_SEND_IDLE: if (DATA_ACK_NOT_SET) { int f = FIFO_Read (&PPR_send_fifo); if (FIFO_ERROR == f) break; WRITE_DATA_LINES ((UINT8)f); DATA_VALID_ON; PPR_timeout = PPR_GET_COUNTER_VALUE() + 5000; PPR_send_status = PPR_SEND_WAIT_ACK; } break; case PPR_SEND_WAIT_ACK: if (DATA_ACK_SET) { DATA_VALID_OFF; PPR_timeout = PPR_GET_COUNTER_VALUE() + 5000; PPR_send_status = PPR_SEND_WAIT_NOACK; } else if (PPR_timeout < PPR_GET_COUNTER_VALUE()) { DATA_VALID_OFF; PPR_send_status = PPR_SEND_IDLE; } break; case PPR_SEND_WAIT_NOACK: if (DATA_ACK_NOT_SET || (PPR_timeout < PPR_GET_COUNTER_VALUE())) PPR_send_status = PPR_SEND_IDLE; break; } }Die schickt irgendwas über nen Hardwarebus
korrekt?
-
Ich mache nur dort Kommentare wo man den Code ohne nicht verstehen würde. Alles andere ist Zeitverschwendung.
-
Shade Of Mine schrieb:
net schrieb:
die variablen sind 'static' d.h. nur in der datei sichtbar. 4 andere funktionen haben noch zugriff darauf.
ah, wie gut dass das keine globalen variablen sind...
Das sind keine globalen Variablen.
Shade Of Mine schrieb:
net schrieb:
geht nicht. gibt keinen c++ compiler für den prozessor wo das läuft
ok, dann kann man auch schoenes C als ersetz nehmen.
wie kommst du eigentlich darauf (wie du weiter oben geschrieben hast), das wäre C+ und nicht ganz normales C?
Musstest du schonmal (in relativ kurzer Zeit) ein Projekt in C fertigstellen? Das man in C genauso schön wie in C++ programmieren kann und C ja eigentlich auch OOP ist, da ja alles nur vom Programmierer abhängt, ist in meinen Augen Aberglaube.
-
DrGreenthumb schrieb:
Musstest du schonmal (in relativ kurzer Zeit) ein Projekt in C fertigstellen? Das man in C genauso schön wie in C++ programmieren kann und C ja eigentlich auch OOP ist, da ja alles nur vom Programmierer abhängt, ist in meinen Augen Aberglaube.
Pardon, eigentlich sind auch fast alle real existierenden C++-Programme genau so häßlich und undurchschaubar wie fast alle C-Programme.
-
stimmt auch wieder.
Aber in C++ wirds einem doch deutlich leichter gemacht "schönen" code zu schreiben. Man kann sich viel kompakter ausdrücken. Für mich gilt immer, je weniger Code desto eleganter. Und da tu ich mich in C echt schwer.
-
Shade Of Mine schrieb:
korrektheit reicht aber nicht, wenn sie nicht wartbar ist (was sie definitiv nicht ist (allein diese makros...))
Da lehnst du dich IMHO ein Stück zu weit aus dem Fenster. Woher willst du eigentlich wissen, dass dieser Code "defintiv" unwartbar ist, hast du es mal versuchen müssen? Sieht eigentlich aus, wie eine ganz klar geschriebene Zustandsmaschine.
Guten code kann man ohne kommentare lesen. den code kannst du soviel kommentieren wie du willst, er ist mies.
Ich kann den ohne Kommentare lesen. Ich weiß natürlich nicht, WARUM die Zustandsmaschine so arbeitet wie sie es tut, und ich weiß auch nicht, was PPR heißt oder sonstige projektspezifische Sachen, aber das ist auch nicht Aufgabe des Codes, das zu erkennen. Dafür gibts Kommentare und Dokumentation.
such lieber mal nach ein paar threads zu diesem thema, das wurde schon oft genug gesagt, dass guter code keine kommentare braucht und unnoetige kommentare den lesefluss stoeren.
Das ist aber kein Fakt, den man irgendwo nachlesen könnte, das ist eine diskussionsbedürftige Behauptung.
-
net hat Recht.
Bye, TGGC (Wähle deine Helden)
-
net schrieb:
Artchi schrieb:
Auf Kommentare kann man verzichten.
ok, dann mal ein beispiel. was schätzt du, macht diese funktion (alle kommentare entfernt)
void PPR_TX_Machine (void) { switch (PPR_send_status) { case PPR_SEND_IDLE: if (DATA_ACK_NOT_SET) { int f = FIFO_Read (&PPR_send_fifo); if (FIFO_ERROR == f) break; WRITE_DATA_LINES ((UINT8)f); DATA_VALID_ON; PPR_timeout = PPR_GET_COUNTER_VALUE() + 5000; PPR_send_status = PPR_SEND_WAIT_ACK; } break; case PPR_SEND_WAIT_ACK: if (DATA_ACK_SET) { DATA_VALID_OFF; PPR_timeout = PPR_GET_COUNTER_VALUE() + 5000; PPR_send_status = PPR_SEND_WAIT_NOACK; } else if (PPR_timeout < PPR_GET_COUNTER_VALUE()) { DATA_VALID_OFF; PPR_send_status = PPR_SEND_IDLE; } break; case PPR_SEND_WAIT_NOACK: if (DATA_ACK_NOT_SET || (PPR_timeout < PPR_GET_COUNTER_VALUE())) PPR_send_status = PPR_SEND_IDLE; break; } }Macht sie irgendwas mit dem Parallel-Port? Kontrolliert die Ausgabe?
-
DrGreenthumb schrieb:
stimmt auch wieder.
Aber in C++ wirds einem doch deutlich leichter gemacht "schönen" code zu schreiben. Man kann sich viel kompakter ausdrücken. Für mich gilt immer, je weniger Code desto eleganter. Und da tu ich mich in C echt schwer.
main(k){for(k=0;k<125;++k)putchar((k+1)%25? ("[k<qFUF>XB]X=9V=hm9FC"[k/6]-52)&1<<k%6?64:32:10);}
Ach was, das klappt doch schon ganz gut.
Ernsthaft, zeig doch mal ein paar größere C++-Programme die schön sind und einigermaßen wenige Bugs aufweisen? Die lassen sich wohl auch an einer Hand abzählen und es ist kein großes Problem, wenn dir zwei, drei Finger fehlen.
C++-Programme sind meiner Erfahrung nach nicht schön, weil sie fett sind. Nicht, weil sie fett sein müßten, sondern weil es anscheind irgendwie zur Philosophie gehört, Dinge so lange zu wrappen, bis man ein 'schönes' Interface hat, das aber noch an ähnlichen Punkten kränkelt, wie das Augangs-Low-Level-Interface (wie viele Indirektionsebenen hat die typische KDE-Anwendung wie der Konqueror bis zu X? Und so ist's ja nicht nur bei der Graphik, alles wird viermal weggepackt und trotzdem stürzt er bei irgendwelchen obskuren Seiten ab. Ärgerlich.). Man gewinnt wenig und macht das Programm durch die Indirektionsebenen trotzdem undurchschaubarer.
Die Lektüre von Bugtraq u.a. zeigt außerdem, daß C++-Software, da wo sie eingesetzt wird, ähnlich versagt, wie C-Software in seinem Bereich, auch wenn man in C++ ein paar Stilmittel mehr hat. Ob das daran liegt, daß die Leute zu doof für C++ sind, oder C++ zu doof für die Leute, sei mal dahingestellt; vom praktischen Gewinn durch C++ habe ich bisher jedenfalls erschreckend wenig gesehen. Überzeug mich
-
Shade Of Mine schrieb:
korrektheit reicht aber nicht, wenn sie nicht wartbar ist (was sie definitiv nicht ist (allein diese makros...)) wird sie irgendwann mal einen fehler beinhalten der nicht reparierbar oder nur mit grossem aufwand reparierbar ist.
die makros trennen den algo von den hardwarezugriffen. das macht die funktion in gewissem maße maschinenunabhängig und gerade das macht sie auch wartbar. ...und ich weiss nicht, warum ein fehler in dieser einfachen funktion 'nicht oder nur mit grossem aufwand' reparierbar sein soll. für dich vielleicht, aber jeder durchschnittlche c-coder hat da keine 10min. arbeit mit.
Shade Of Mine schrieb:
ok, dann kann man auch schoenes C als ersetz nehmen.
anfangen wuerde ich mit schoenen namen und dann die makros etwas kuerzen. schon haetten wir etwas lesbareres.änder' die funktion mal nach deinen vorstellungen und dann poste sie hier. ich bin mal gespannt
Talla@home schrieb:
Die schickt irgendwas über nen Hardwarebus
korrekt?bingo
DrGreenthumb schrieb:
Aber in C++ wirds einem doch deutlich leichter gemacht "schönen" code zu schreiben.
naja, guck dir mal den code der stl an oder irgendwelche ellenlangen 'cout' statements mit den ganzen stream-modifiern, static-casts usw. da drin. glaub nicht, dass das 'schöner' code ist.
-
net schrieb:
naja, guck dir mal den code der stl an oder irgendwelche ellenlangen 'cout' statements mit den ganzen stream-modifiern, static-casts usw. da drin. glaub nicht, dass das 'schöner' code ist.
Yeaha! - Bei jedem neuen Projekt nehm ich mir vor "Diesmal aber nur reines C++" und lande spätestens beim byteweisen Einlesen von Dateien wieder bei den C Pendanten. Naja, man soll die Hoffnung nie aufgeben
BTW: Ich mag deinen Quelltext. Nur die Funktionsbezeichner sind fast genauso benannt, wie irgendwelche #defines.
-
@Daniel E. Auch der C Programmierer abstahiert durch die funktionale Programmierung.
Würden wir das nicht tun, könnten wir ja gleich Assembler programmieren. Ein
Wrapper wird ja nur geschrieben, wenn man etwas fundamental ändern will. z.B.
eine C-Library zu einem C++ Interface umzuprogrammieren. Aber wer würde z.B.
einen Wrapper um GUI- C++ -Klassen, wie die wx Windows schreiben?Natürlich wird man wieder eine Klasse schreiben, um die grafische Oberfläche zu
repräsentieren. Aber welcher C-Programmierer würde sich nicht dafür auch eigene
Funktionen schreiben, um Front- und Backend zu trennen?
-
Ob das daran liegt, daß die Leute zu doof für C++ sind, oder C++ zu doof für die Leute, sei mal dahingestellt;
In den meisten Fällen bestimmt ersteres.
Ich glaube aber auch nicht das ein C++ Projekt im ganzen viel schöner ist, als eins in C. Es ist eher die Kosmetik im Detail. Eine simple, 2-Zeilen-C++-Funktion ist oft gleich 3x so lang wegen ner blöden string-konstruktion.
