Werden bei euch Kommentare gemacht?
-
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.
-
Bashar schrieb:
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.
Muessen aber gute Kommentare sein, wenn sie erklaeren warum es DATA_ACK_SET und DATA_ACK_NOT_SET gibt, oder warum FIFO_Read Fehler ignoriert werden, oder warum eine Funktion TX_Machine heisst und vorallem was sie macht und welche seiteneffekte sie hat, oder welche seiten effekte DATA_WRITE_LINES(int) oder DATA_VALID_OFF/ON haben, oder warum manche makros klammern haben und andere nicht,...
Die Struktur kann man natuerlich nur mit Dokumentation verstehen:
warum auf ein NO_ACK gewartet wird, woher diese 5000 kommen, was diese 3 zustaende machen, wo der unterschied bei PPR_SEND_WAIT_ACK zwischen ACK_SET und ACK_NOT_SET ist, etc.bleiben dennoch die ganzen seiteneffekte, die viel dokumentation erfordern (wenn die fehlen sollte hat ein programmierer vermutlich grosse probleme mit dem code). daraus schliesse ich mal: der code wird nicht leicht wartbar sein.
das problem sind IMHO die seiteneffekte - wehe wenn da jemand etwas zu dokumentieren vergisst (was ja sehr schnell passieren kann)
natuerlich kann ich auch falsch liegen und alle diese punkte haben einen vernuenftigen grund.
-
Das ist aber ein typisches Codebeispiel für eine Hardwareschnittstelle... wenn ich mir überlege, Profibus, OPC, Serial, IEEE, das hat nachher im Code immer so wie dieses Beispiel ausgesehen. Nie besser, manchmal schlechter, weil einer irgendwo noch ein
sleep(200);
reingepackt hat.
Das liegt schon daran, weil viele Codes und Kürzel noch ziemlich nahe aus der IO-Definition kommen und aus dem Assembler-Layer, der sich dahinter versteckt. Natürlich könnte man die ganzen Defines und Zustände, sowie auch die Funktionen des Interface, in saubere Wrapper packen, statt Fehlerflags könnte man das über Exceptions lösen, usw.
Die Frage nach dem Mehrwert stellt sich aber - mehr als funktionieren kann es nicht.
Schreibt man nun eine zusätzliche Wrapperebene, um das sauber über OOP zu lösen, besteht die Gefahr, daß man sich in der eigenen Logik irrt, bzw. daß diese neue Ebene nicht zu 100% zu der Zustandsmaschine vom Bus passt. Man benötigt sehr gute Kenntnisse des Interfaces, um das zu wrappen.
Für einen Wartungsprogrammierer, der nun die Schnittstelle kennt, schafft man mit dem Zwischenlayer eigentlich mehr Verwirrung, weil der nun die proprietäre Wrapperlogik auch verstehen muß.
Aber wenn man die Busdoku gelesen hat, kann man das C-Fragment sofort verstehen... daß der Wartungsprogrammierer die Buslogik bzw deren wichtigen Register/Zustände kennt ist ohnehin notwendig, was anderes ergibt keinen Sinn, ohne diese Kenntnisse kann er gar nix machen. Aber mit den Kenntnissen ist das durchaus gut lesbarer Code.
Apropos, ich kann Dir sagen warum der FIFO_ERROR ignoriert wird - der Programmierer war so froh, daß das Senden im Gut-Fall überhaupt funktioniert und der Code arbeitet, so daß er lieber die Finger vom Fehlerfall weggelassen hat. Außerdem weiß er, daß wegen des verwendeten Protokolls weiter oben kein Fehlerhandling gemacht wird, wahrscheinlich senden sie die Daten nochmal, wenn keine Quittung kommt, daher ignoriert er Sendefehler auf dieser Ebene einfach.
-
Marc++us schrieb:
Schreibt man nun eine zusätzliche Wrapperebene, um das sauber über OOP zu lösen, besteht die Gefahr, daß man sich in der eigenen Logik irrt, bzw. daß diese neue Ebene nicht zu 100% zu der Zustandsmaschine vom Bus passt. Man benötigt sehr gute Kenntnisse des Interfaces, um das zu wrappen.
naja, also diese funktion ist eine von 3 state-machines, die von einer übergeordneten logik (auch 'ne state machine) aufgerufen werden. da muss man nix wrappen. das ding ist in sich geschlossen und arbeitet autark. das interface für dieses protokoll ist denkbar einfach - die darüberliegende schicht kommuniziert mit 2 fifos (es gibt nur 2 interfaces, non-blocking, die nach aussen gehen), einen in den sie daten reinschreiben kann, die dann vom busprotokoll versendet werden und einen, aus dem sie daten rausholen kann. das könnte man schon wrappen, wär auch nicht zeitkritisch, aber wozu?
Marc++us schrieb:
Apropos, ich kann Dir sagen warum der FIFO_ERROR ignoriert wird - der Programmierer war so froh, daß das Senden im Gut-Fall überhaupt funktioniert und der Code arbeitet, so daß er lieber die Finger vom Fehlerfall weggelassen hat.
FIFO_ERROR wird nicht ignoriert, sondern führt dazu, dass die funktion im idle-state bleibt ohne was zu machen. das ist absichtlich so. zu den seiteneffekten: mir sind keine bekannt. sollte sich der andere busteilnehmer nicht konform verhalten, hat er eben pech gehabt, aber er kann den code nicht zum abstürzen bringen oder sonst ein undefiniertes verhalten erzeugen.
btw: der bus arbeitet bidirektional, ist interrupt-gesteuert, umschaltung der datenrichtung usw. macht er alles selbständig. der bus hat einen master und kann beliebig viele slaves haben. der master bestimmt die richtung der datenleitungen, die vom jeweiligen slave bestätigt werden muss. der code hier tut schon seit jahren unermüdlich seinen dienst ohne die geringsten ausfallerscheinungen. das hier war einfach nur die sendefunktion
hehe, schon witzig zu welch langen debatten so'n codeschnipsel führt. eigentlich wollt' ich nur zeigen wie nackt das ohne kommentare aussieht...
-
Shade Of Mine schrieb:
Muessen aber gute Kommentare sein, wenn sie erklaeren warum es DATA_ACK_SET und DATA_ACK_NOT_SET gibt
Die Spezifikation der darunterliegenden Hardware zu erläutern ist nicht Aufgabe von Kommentaren.
oder warum FIFO_Read Fehler ignoriert werden
Wo soll das sonst stehen, wenn nicht in einem Kommentar?
, oder warum eine Funktion TX_Machine heisst
TX ist eine domänenspezifische Abkürzung, nehm ich an. Wenn du einen XMLBlahBlah schreibst, weiß vielleicht auch irgendeiner nicht, was XML heißt, schreibst du es deshalb aus? Wichtig ist, dass die, die an dem Programm arbeiten, mit TX was anfangen können.
Machine steht für Zustandsmaschine. Für die gibts vermutlich irgendwo auf Papier eine Spezifikation, und dort steht auch, warum die diese Zustände und Übergänge hat. Im Code hat das nichts zu suchen.bleiben dennoch die ganzen seiteneffekte, die viel dokumentation erfordern (wenn die fehlen sollte hat ein programmierer vermutlich grosse probleme mit dem code). daraus schliesse ich mal: der code wird nicht leicht wartbar sein.
Das was du Seiteneffekte nennst sind der ganze Sinn und Zweck dieser Funktion.
das problem sind IMHO die seiteneffekte - wehe wenn da jemand etwas zu dokumentieren vergisst (was ja sehr schnell passieren kann)
Ich hoffe, dass hier die Dokumentation vor der Software kam.
-
DrGreenthumb schrieb:
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.
Dann stimmt auch zweiteres. Der "Computer" hat sich an den Menschen anzupassen und nicht umgekehrt.
-
Suchender schrieb:
Der "Computer" hat sich an den Menschen anzupassen und nicht umgekehrt.
Das ist zwar wünschenswert, aber in der Praxis erweist sich der Computer (bzw. dessen Interfaces) doch regelmäßig als ein relativ starres Stück Schrott, das unbeweglich ist und in keinster Weise flexibel oder anpassungsfähig.
So daß die gesamte Flexibilität vom Softwareentwickler eingebracht werden muß.
-
Der Computer ist mehr als nur der Bildschirm den Du immer siehst, weiß Du
-
Was willst Du damit sagen?
-
Mit Computer meinte ich schon das Gesamtsystem mit SW und nicht nur das Stückchen Metall. Wenn dieses Gesamtsystem von vielen nicht benutzbar ist, liegt das an den Entwicklern des System und nicht an den Benutzern.
-
BTW So sieht unwartbare Software aus: http://www.thedailywtf.com/ShowPost.aspx?PostID=31320
Das zu sehen verursacht mir körperlichen Schmerz und Übelkeit, das ist einfach nur noch angsteinflößend, nicht mehr lustig.
-
Suchender schrieb:
Mit Computer meinte ich schon das Gesamtsystem mit SW und nicht nur das Stückchen Metall. Wenn dieses Gesamtsystem von vielen nicht benutzbar ist, liegt das an den Entwicklern des System und nicht an den Benutzern.
Dann solltest Du das Posting von Marc++us nochmal lesen.
-
Marc++cus meinte das Strösesup auch fehlbar ist? Mit dieser Aussage bin ich einverstanden.
-
Bashar schrieb:
, oder warum eine Funktion TX_Machine heisst
TX ist eine domänenspezifische Abkürzung, nehm ich an. Wenn du einen XMLBlahBlah schreibst, weiß vielleicht auch irgendeiner nicht, was XML heißt, schreibst du es deshalb aus? Wichtig ist, dass die, die an dem Programm arbeiten, mit TX was anfangen können.
Machine steht für Zustandsmaschine. Für die gibts vermutlich irgendwo auf Papier eine Spezifikation, und dort steht auch, warum die diese Zustände und Übergänge hat. Im Code hat das nichts zu suchen.Das Problem an der Bezeichnung dieser "Prozedur" ist nicht das Kürzel. Das Problem ist, dass eine Prozedur etwas macht und der Bezeichner dieser Prozedur nicht damit in Einklang zu bringen ist. Bei dem Bezeichner sollte es sich mehr oder weniger um ein Verb handeln und nicht um ein Substantiv. Wenn ich mich hier frage, was die Prozedur macht, dann heißt die Antwort "Die macht Maschine.". Das macht keinen Sinn. Der Bezeichner ist widersprüchlich zum sprachlichen Konstrukt und hemmt somit das Verständnis. Insofern ist der Bezeichner hier eindeutig ein Faktor, der zur Unlesbarkeit und Unwartbarkeit des Codes beiträgt. Wie stark sich das auswirkt und inwiefern die Prozedur weiterhin als Lesbar und Wartbar gelten kann, wird natürlich noch von weiteren Faktoren abhängen. Aber es ist natürlich richtig, wenn man sagt, dass der Bezeichner hier so schlecht gewählt ist, dass mehr Dokumentation nötig ist, um die Prozedur zu verstehen.
-
Was hier die meisten (vor Allem Shade) übersehen (ausser Bashar und Marcus) ist die Tatsache, dass ein PC nicht die einzige programmierbare Komponente ist. Nets Code stammt - wies Marcus richtig gesagt hat - definitiv aus einem Embedded-System und ist definitiv als Statemachine für eine Bustransmission zu erkennen. (Daher übrigens auch der Einwand wegen C++. Embedded C++ ist nicht halb vergelcihbar mit dem Standard C++.)
@Shade: Global != Global. Denn Static-Globale Variablen sind Modulglobal. Das Heisst für den Rest des Projekts unsichtbar. Bei Embeddedsystemen ist man manchmal schlicht gezwungen, modulglobale Variablen zu benutzen um sich die Pushs und Pops zu sparen. Man kann von der gewöhnlichen PC-Programmierung nicht einfach auf Embedded Code schliessen. Dort herrschen komplett andere Zustände und Verhältnisse. Fängt beim Speicher (ROMgrösse und RAM) an und hört beim timing auf. Da fallen viele drauf rein. Auch Volkard kürzlich.
Ich möchte mich auch nicht weiter darüber auslassen. Nur möchte ich einen weiteren Aspekt in die Diskussion einbringen:
Über Zeilenweise Kommentare kann man streiten (Ich persönlich bevorzuge abschnittsweise Beschreibungen des Warums und der Wiesos zwecks Nachvollziehbarkeit). Was allerdings nie fehlen darf ist eine Aufzeichnung der Analyse und des Designs der applikation! (Welches Modul mit wem und wie)
Hab selber kürzlich son Projekt an die Backe gekriegt zwecks Änderung. Das Ende vom Lied: Wahrschleinlich hat das Projekt jetzt mehr redundanzen denn je. Aber das nur weil sie nie jemand die Zeit genommen hat, das ganze App. Konzept aufzuzeichnen. Das Wissen existiert nur in den Köpfen der Urheber. Und selbst da noch verteilt. Für mich als Transferboje für dieses Know-How völlig unbrauchbar.
-junix
-
Shade Of Mine schrieb:
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.
Ahja! Den Satz will ich nicht unkommentiert lassen!
Ich weiss nicht wie du das siehst, aber dank der durch Syntax Highlighting unterschiedlichen Farben dürfte das gedankliche Ausblenden der Kommentarzeilen kein Problem sein. Man kann sie ja sogar mal hellgrau statt grün machen, damit sie noch weniger ins Auge stechen. Dieses Argument lasse ich schlicht nicht gelten!
-junix