Werden bei euch Kommentare gemacht?
-
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
-
Darf ich jetzt auch mal was sagen?
Ich will ja nicht kleinlich sein, aber wer sagt, er vertehe seinen Code und kommentiert deswegen nicht, der ist ein nicht teamfähiger Idiot.
Man kommentiert nicht gern, weil es Zeit kostet. Es mag auch sein, dass man durch seinen Quellcode (bei mir sinds aktuell lediglich 6000 Zeilen) problemlos versteht, aber das Grundlegende habt ihr vergessen.
Ihr kommentiert nicht für Euch!
Ich musste auch schon dur tonnenweise unkommentierten Salat steigen und das ist das Grausamste was einem Programmierer unterkommen kann - neben dem Auftraggeber der nicht weiß, was er eigentlich will..Kommentare sind dazu da, damit auch andere Leute euren Quellcode verstehen können, wenn ihr mal nicht da seit.
Überhaupt hat ein Programmierer nur 3 Todesursachen zu erwarten:
1. Herzschlag wegen zu Hohem Kaffeekonsum
2. Selbstmord aus Verzweiflung wegen unlesbarem Quellcode
3. Meuchelmord, aufgrund unlesbaren Quellcodes.Programmierer - gerade die, die an großen Projekten arbeiten dürfen erst garnicht davon ausgehen, dass sie ja ihren Code verstehen. Den Godlike programmer der unentbehrlich ist gibts nicht mehr. Entweder man arbeitet vernünftig oder garnicht. Es gibt inzwischen genug Programmierer. Man muss sich nur einen einfangen der auch kommentiert.
Okay. Da ihr euch bis hier unten durchgeforstet habt : Der Kommentar von oben mit dem Idioten ist ein wenig arg überzogen, aber wer das Kommentieren aus o.g. Gründen nicht macht, der hat einfach den Sinn dahinter nicht verstanden..
cYa
DjR
-
Sehr schön ausgedrückt (o:
Eine kleine Ergänzung vielleicht:
Gewisse Dokumentation die man schon vorab erstellen kann (Applikationsmodell) zwingt einem auch zum deutlicheren durchdenken des ganzen Konzepts...-junix