D.h. aber, dass du es ausschließt, dass jemand anderes mal eine Änderung an deinem Video-Kodier-Projekt vornimmt.

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.
_________________Farin Urlaub - Bewegungslos

a) Nein. Denn wie schon gesagt, bisher hatten alle leute die meinen code in die finger bekommen haben nie groß probleme gehabt ihn zu verstehen und ggf. zu ändern.

b) Ja. Denn immerhin verdiene ich dann Geld mit Wartungsarbeiten

Ich halte es für einen ziemlichen Trugschluss, wenn man annimmt, dass der eigene Code verständlich ist, nur weil man selbst ihn versteht und ein paar andere Leute ihn sich angesehen und verstanden haben.
Es zeugt ja nicht von schlechtem Programmierstil, wenn der Code sich nicht so leichtverständlich wie ein Buch liest, es ist meiner Meinung nach hingegen schlechter Programmierstil, wenn man nicht eine zum Code korresponierende Dokumentation hat, die sich wie ein Buch liest. Ich habe früher oft Projekte in Abteilungen geschrieben, in denen extrem spärlich dokumentiert wurde, und keiner hatte ein Problem damit, weil jeder wusste, worum es geht und jeder alles verstanden hat. Und dann kommt ein neuer hinein und der ist wochenlang mit der Einarbeitung beschäftigt, weil er nur im Quellcode rumspringt und gerade dieser einen Person eine Spardokumentation nicht ausreicht. Und wenn es nur eine Person gibt, die den Quellcode nicht einfach so durchlesen kann, ist der Code nicht selbsterklärend.

In diesem Sinne hat Phobeus wohl Recht, dass nur Funktionen ala selbsterklärend sind...

Nicht mal zwingend!
Wohin wird "Hello World" denn ausgeben? Ein OpenGL Kontext? StdOut? direkt in eine Datei? Textdatei, Dokument oder Bild?
Und wie sind die Parameter bei den Ausgaben? Textarbe? Größe? Schriftart?
Viele Projekte nutzen ja parallel eine GUI und das Terminal, um Fehler oder Informationen auszugeben.
Und was für Vorraussetzungen müssen erfüllt sein, damit ich sayHelloWorld(); ausführen kann? Vielleicht will ich Code ja nicht nur grob verstehen oder Kleinigkeiten ändern, sondern was komplett eigenes machen, was aber Teile des alten Codes nutzt. Wo ist sayHelloWorld denn definiert? Was gibt es für Vorraussetzungen an das Projekt? Welche Funktionen müssen vorher (z.B. für das Initilisieren) aufgerufen werden? Und was muss das System leisten für "sayHelloWorld"? Brauch es bestimmt Bibliotheken? Fragen über Fragen...

LG Ziz

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.
_________________Farin Urlaub - Bewegungslos

Wenn du die fragen alle zu jeder Funktion in einem Hilfe-kommentar erklärst hast du aber am ende nen ordentlich dickes buch vollgeschrieben..

Naja, wenn man ein Buch gut strukturierst, ergibt es sich von selbst, aber vorallem hat man einen Komplettüberblick und muss nicht im Code rumraten.

Man schreibt ja auch nicht bei JEDER SDL-Funktion, dass man doch bitte SDL_INIT(); vorher aufrufe, aber es wird in der Dokumentation erwähnt, dass dies stets der erste Schritt ist.

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.
_________________Farin Urlaub - Bewegungslos

Aber solche dinge sind auch was eine sache unübersichtlich macht etc.. auf dinge "Wenn ich das will, muß ich erst das machen" verzichte ich in der Regel immer.. das ist ja auch der sinn von OOP, alles sollte eigenständig funktionieren.

Ich kann jede klasse meiner lib einzeln verwenden ohne den rest anzufassen... will ich ein OBJ laden, nehme ich meine normale CIMesh klasse dafür und kann damit alles tun was ich will.. denn die funktioniert auch ohne das OpenGL oder sonstwas initialisiert wurde. Es gibt auch nicht die gefahr das man ausversehen etwas aufruft was OpenGL vorraussetzt, denn mit OpenGL kommt nur der Renderer in berührung, und der initialisiert alles was er braucht im constructor etc.

Bei mir greifen halt alle dinge ineinander, sind aber trotzdem alle einzeln völlig frei und unlimitiert benutzbar.

Dementsprechend fällt alles an doku á la "Erst das, dann das, dann das" weg.
Und ich weiß wirklich nicht - um beim beispiel zu bleiben - was es bei einer Mesh klasse nicht zu verstehe gibt...

Sie hat ne funktion "loadFromStream/File", und dinge wie get/set Vertex, Normal, Color, Attribute etc.. alles durch die funktions namen selbst erklärend.

Und so handhabe ich es halt bei all meinen klassen etc.

Aya

Ernsthaft, ich habe einen solchen Code noch nie live gesehen Gerade die Grundbedingungen, die erfüllt sein müssen, damit bestimmte Klassen verfügbar sind ist einer der Herausforderungen bei größeren Projekten... und zwar in einer Größenordnung, dass man ganze Bücher damit gefüllt hat um Konstrukte zu schaffen, die überhaupt erst diese Problematik halbwegs überschaubar machen. Eine Bibliothek, die ihre Schnittstellen nicht nach außen dokumentiert sind schlichtweg für Dritte unbrauchbar. Eine fehlende interne Dokumentation behindert die Weiterentwicklung arg. Ich würde ja gerne mal Code von Dir sehen, weil ich bisher keinen solchen Code gesehen habe.

Genau die Frage: Was kann jemand an dem Code nicht verstehen. Ist ja gerade essentiell für eine solide Dokumentation. Und jede konkret implementierte Klasse wird Fragen aufwerfen... und sei es eben nur, ob Parameter Pflicht oder optional sind und wie sich dadurch der Ablauf verändert. Gerade bei OSS-Projekten gibt es auch genug Negativbeispiele. Ein Kommentar a la "Die Methode sayHello gibt Hello aus" kann man sich schenken, da man auch den Code durchlesen kann. Ziz hat bereits gezeigt, warum eine solche für den Entwickler unmissverständliche Funktion, bei jemand anderen weitere Fragen aufwerfen kann. Zum Thema: Andere Entwickler verstehen den Code ... bei einem komplexen Projekt wird hoffentlich eben nicht jeder verdonnert sämtlichen Code zu lesen. Gerade dort wird man eine gute Dokumentation zu schätzen wissen, wenn es einem eigentlich nur um Schnittstellen geht.

Meiner Erfahrung nach hilft es auch nicht darüber zu diskutieren. Wer die Notwendigkeit nicht sieht, bekommt hoffentlich mal ein Projekt bei dem er/sie dem Entwickler die Pest an den Hals schicken, weil wieder mal ein Verhalten nicht dokumentiert wurde... und niemand schreibt größere Projekte komplett von Grund auf an neu...

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."