Die Doku-Kommentare kennst du? siehe dazu auch: Kommentation

Oh - ich fürchte, da gibts garkein Standard-Vorgehen.
Also Programme zu dokumentieren ist eminent wichtig, und ist State of Art, aber derlei Dokumentationen richten sich an Programmierer, nicht an Laien.
Laien erklärt man, was das Prog tut, und wies zu bedienen ist, nicht aber, aus welchen Komponenten es zusammengesetzt ist, und wie die interagieren.

Wie gesagt: imo kein Standard möglich. Dem einen Laien kannste mit UML kommen, dem anderen ganz sicher sicher nicht. Und auch nicht standardisierbar ist, wieweit du ins Detail gehen willst oder kannst (hängt ja auch von Auffassungsgabe und Vorwissen des Gegenübers ab).

also doch Dokumentation für Programmierer. Na, dazu habich meine Meinung ja in Kommentation kundgetan, nämlich: schreibe guten Code und wenig Kommentare.
Guter Code erklärt sich selbst,
und zusätzliche Erklärungen beleidigen dann den Intellekt des Lesers, lenken vom wesentlichen ab, und lügen, wenn der Code geändert wird, und die Nachbesserung der Komentation vergessen.

Ich zB. kommentiere den grundsätzlichen Aufbau eines Progs, und b.Bed. auch die Verantwortlichkeit der verschiedenen Klassen.
Darüber hinaus nur ausnahmsweise, bei besonders eigenartigen oder listigen Konstrukten.

Auf diese Weise erhält der Leser eingangs eine Orientierung, was das ganze soll, und dann kann er im Code selbst nachlesen, dasses tatsächlich so funktioniert, wie eingangs behauptet.
Wenn der Leser nix kapiert, weil ihm programmiererische Kenntnisse fehlen, kannichnix dafür. Eine Programm-Doku ist eine Programm-Doku und kein Programmierkurs für Anfänger.

na, doch. Bei mir ist Programmierer, wer programmiert Ob ers gut macht, oder ühaupt kann, ist eine annere Frage

mein wichtigster Rat ist halt: schreibe guten Code. Das vlt. wesentlichste daran ist, vernünftig zu benamen, also wer die berühmte "Textbox1" in seiner Anwendung rumfahren hat, der fällt durchs Examen.
Nenn das blöde Ding "txtUserName" oder whatever, und schon brauchst du einen Kommentar weniger zu schreiben.

Hi
ich denk' mal, dass sich UML, eine hierarchische Dokumentationsweise usw. eher bei richtig großen, unüberschaubareren Projekten anbietet. Die meisten Programme im Forum dürften auf ein spezifisches Problem beschränkt sein und daher im Allgemeinen noch relativ übersichtlich. Eine Dokumentation der einzelnen Typen und Mitgliedern ist sinnvoll, eine Kommentierung von nicht offensichtlichem Vorgehen gehört ebenfalls dazu. D.h. Kommentare wie
If a = b Then//vergleicht, ob a und b gleich sind
gehören nicht zu der sinnvollen Art (siehe MDX *hust*) und sind mehr nervig, als nützlich, wenn man wirklich mal auf Fehlersuche ist. Ein Bezeichner sollte allerdings schon seinen Sinn kundtun, sodass die Dokumentation wegfällt. Also ist a oder b kein wirklich sinnvoller Bezeichner. Ich bin immer der Meinung, man sollte sich auch an die Vorgaben der Umgebung halten (d.h. öffentliche Membernamen groß, Parameternamen klein usw. oder so)

Ich denke mal, dass du selber entscheiden solltest, in was für einem Rahmen du eine Dokumentation anfertigst. Mach' dir einfach mal Gedanken dazu, was du benötigen würdest, wenn du an dein Programm rangehen würdest. Umfangreichheit ist immer relativ gesehen und ein schlechtes Maß für die Komplexität eines Programmes. Praktisch wäre eine Dokumentation in Textformat, bei der man einen groben überblick erhält, eine Einteilung in Ordner und Namensräumen, die jeweils ebenfalls eine Dokumentation erhalten und evtl. echt ein Klassendiagramm.
Ich will mich hier nicht zu weit aus dem Fenster lehnen, ich bin nur Student und habe keine große Erfahrung in dem Thema. Meine bisherigen Projekte, sind größtenteils nicht darauf ausgelegt, von anderen gelesen zu werden, d.h. die Dokumentation ist vorhanden, aber nicht für "Laien" ausgelegt, die sich ohne Vorwissen in meine Programme einarbeiten wollen. Trotzdem denke ich, dass es wichtig ist, die Dokumentation nur mit nicht offensichtlichen Elementen vollzupacken und auf wesentliche Aspekte zu beschränken. Wenn man ein Klassendiagramm über 5000 zusammenhangslose Klassen hat, kann man das vielleicht als Tapete verwenden, aber sonst ist der Sinn evtl. eher fraglich.

Noch was zur Architektur:
Achte auf jeden Fall darauf, dass dein Code sauber ist, Redundanz vermieden wird, Klassen mit sich überschneidenden Inhalten in vererbbaren Klassen zusammengefasst werden, usw. Nachträgliche Ausbesserungen sind extrem nervig. Lieber auch mal auf eine abstrakte Klasse oder ein Interface zurückgreifen, wenn du nachträgliche Optimierungen vornehmen kannst oder möchtest (z.B. IDictionary statt einem Dictionary, das später durch ein manuell implementiertes als Hashtable gestaltetes Dictionary ersetzt werden soll). Es wäre auch gut, das Programm so zu gestalten, dass nachträgliche Änderungen sehr einfach und Probleme sehr leicht zu beheben sind. Also Abstraktion im Hinterkopf behalten, aber nicht über das Ziel hinausschießen. Nachträgliche Änderungen sind zeitaufwändig und lästig, da man an allen Ecken und Enden etwas ändern muss, aber eine Abstraktion selbst einzuführen ist meist auch nicht gerade schnell passiert.

Gruß
~blaze~

Am wichtigsten ist, wie wir ja wissen, vorher schon genau zu definieren was das Programm machen soll. Das wäre schon mal ein guter Einstieg in die Dokumentation. Danach noch eine kurze Erklärung der Funktionen intern.

Für die internen Funktionen brauchst du nicht viel machen. Fasse die Formeln zu Gruppen zusammen (Berechnungen, Datenbankzugriff usw.) und beschreib nur die Funktionen, die wichtig sind. Alle nicht so wichtigen Funktionen werden im Programmcode über die Kommentare erklärt (XML-Kommentare).

Auf simple Methoden brauchst du auch nicht näher eingehen. z.B.: Wenn du eine Methode mit dem Name "WriteLog" hast die einen String als Parameter annimmt, dann sagt das doch schon so ziemlich alles aus, was man darüber wissen muss. Wer dann noch genau wissen möchte, wie geloggt wird, der muss sich halt den Code ansehen.

Eine Standardmethode zur Dokumentation von Klassen, Methoden, Properties und Variablen besteht darin, in der Leerzeile darüber einfach mal 3 Kommentarzeichen einzugeben:
Da hast Du schon mal ein gutes Dokumentationsgerüst.
Mit einem Haken im Projekt:
Eigenschaften -> Compile -> Generate XML documentation file macht Dir der Compiler sogar aus all diesen Kommentaren einen XML-File, der auch von anderen Werkzeugen genutzt werden kann.
Und noch besser: Du bekommst eine Warnung, wenn eine Public Klasse / Methode / Property / Variable nicht so kommentiert ist.

Ich finde diesen Haken nicht, oder ist es nur für VisualStudio Anwender vorhanden?

Da isser (2010 Ultimate).