An sich selber scheitern :-)

[Flow_cplus]

Hi

Kennt ihr das: Man holt(oder findet zufällig) wiedermal ein schon etwas älters (min 2 Monate) halbangefangenes Projekt heraus und denkt sich motivert, das überarbeite ich jetzt mal, damit ich da mal vorwärts komm.

Das Problem, man versteht seinen eigenen Code nicht mehr und fragt sich verzweifelt, was hab ich denn da gemacht?? Teils weils Schrott war, teils weil ich einfach nicht mehr weiß was ich damals gedacht hab, oder vor hatte, da ja maches mit Blick auf die Zukunft so und so impelemtiert wurde.

Und ich hab grad das witzige Unterfangen sowas auszuklamüsern, ..mmh

Jetzt kann natürlich jeder sagen: und deswegen immer brav kommentieren!! Stimmt ja auch, nur dachte ich meistens bei Coden, des wird jetzt eh nur ein Erstentwurf oder ich machs noch so und so weit fertig und dann kommentier ich ... nur kams nie soweit!!

Naja, so macht halt jeder seine Erfahrungen

Was habt ihr denn da so für Erfahrungen, oder seit ihr alle so konsequent, dass euch sowas nie passiert??

Grüße Flow

[No Name]

Naja, in 'früheren' Tagen ist das oft so gewesen.
Das gibt sich aber mit der zeit.
Man fängt an zu 'lernen' , zu verstehen wie man den eine 'ordentliche' Planung setzt, samt Zeitplan.

Schau dir doch einfach mal Bücher über Softwareplanung /Entwicklung an.
Analysiere deine Fehler, lege die Sache über Lösungswege die in solchen Büchern behandelt werden.

Fang an dir feste Zeitpläne zu setzen, feste Ziele die ereicht werden müssen ( Milestones ).

Mit der Zeit gibt sich das alles, don't Panic

[Marilyn]

Im Hobbybereich sich Milestones zu setzen finde ich etwas übertrieben, denn wenn man noch Studium, Arbeit, RL, etc. unter einen Hut bringen muss, kann man die in der Regel sowieso nicht einhalten, weil immer was dazwischen kommt. (es sei denn natürlich man hat etwas länger frei, dann sieht das anders aus). Für den prof. Bereich gebe ich meinem Vorredner aber vollkommen recht.
Aber ich glaube, die Frage war auch eher, wie es mit der Dokumentation des Codes aussieht. Hier machen, die vorher erwähnten Bücher allerdings auch Sinn: ein Pflichtenheft beispielsweise ist immer recht nützlich (wenn es sich nicht gerade um ein Tool handelt, was man an einem Wochenende fertig hat).
Und auch den Code dokumentiere ich persönlich recht anständig. Jede Funktion / Prozedur / Methode bekommt einen Kommentar, was sie leistet, was an ihr noch verbessert wird und worauf man achten muss... und das, sobald sie ansatzweise ein paar Zeilen Code enthält. Das selbe gilt für jedes Objekt. Jede Datei enthält also einen 'Header', in dem Name des Autors, Datum der Erstellung, Datum der letzten Änderung, Art der Änderung und eine Kurzbeschreibung enthält, was in dieser Datei zu finden ist. Darüber hinaus eine Todo-List mit den bekannten Bugs oder noch fehlenden Features. Wenn man das konsequent macht, bekommt man auch nicht so schnell Probleme, wenn mal andere Programmierer an dem Projekt was überarbeiten wollen. Man macht sich auch selbst einen Gefallen, wenn man das ganze in Englisch hält, weil wer weiß schon, wo der Code mal landet?
Der (Funktions-)Code an sich, ist bei mir recht unterschiedlich kommentiert... Recht trickreiche Passagen oder Dinge, für die ich recht lange gebraucht habe, sind immer kommentiert. Der restliche Code ist so kommentiert, wie es meine Laune gerade zulässt.

Anfangs habe ich das natürlich auch nie so konsequent durchgezogen, aber wie schon gesagt wurde: man lernt mit der Zeit. Und spätestens, wenn du mal an einem Projekt sitzt, das ein anderer angefangen hat und du es korrigieren/zu ende bringen sollst, wirst du über jede Kommentar-Zeile froh sein. Ich hatte auch schon mal das Glück das nicht eine Zeile Kommentar in einem Code (mehrere 100 Zeilen Code) zu finden war und das Resultat war, dass ich den Code komplett neu geschrieben habe!

PS: Man sollte es mit Kommentaren auch nicht übertreiben. Wer z.B. "i++; //erhöht i um 1" schreibt, hat den Sinn nicht verstanden, dann sind Kommentare eher hinderlich. Ein gesundes Mittelmass ist also zu finden.

[Gregor]

Original erstellt von Flow_cplus:
**
Was habt ihr denn da so für Erfahrungen, oder seit ihr alle so konsequent, dass euch sowas nie passiert??
**

1. Ich kommentiere meinen Code eher sehr wenig.

2. Ich weiß bei meinem aktuellen Projekt auch nach Monaten wieder recht schnell, was was ist und wo man was machen kann. Das liegt wahrscheinlich daran, dass ich sehr kleine Klassen (Schnitt: 50 Zeilen/Klasse) habe, die alle relativ aussagekräftige Namen haben. Zudem ist das Programm relativ modular aufgebaut, so dass ich mich meistens nur mit einem kleinen, überschaubaren Bereich befassen muss.

[Bill Geiz]

Ich mache eigentlich ziemlich genau die gleichen Erfahrungen wie flow_cplus. Bei jedem neuen Projekt nehme ich mir dann vor, es anständig zu kommentieren und so eine einigermaßen ordentliche planung zu machen, doch meistens lassen ich dann von meinen guten Vorsätzen ab und zieh es nur am anfang konsequent durch und frage mich dann auch später, was der code bedeuten soll. Das ist vorallembei großen Projekten sehr hinderlich, so dass ich versuche es konsequent durchzuziehen.

[Shade Of Mine]

ich kommentiere eigentlich garnicht (es sei denn, ich arbeite an einer library, dann kommentiere ich nur soviel um mit doxygen eine doku erstellen zu können)

in der arbeit kommentiere ich aber recht viel.
das hat den grund: an hobby projekten kann ich ewig sitzen, da werfe ich ab und zu mal das design um, oder überlege mir eine woche lang wie ich das am besten designe - aber in der arbeit geht das nicht. da ist man dauernd unter zeitdruck und ich versuche die aufgabe möglichst schnell und möglichst fehlerfrei hinzubekommen - darunter leidet natürlich die code qualität

aber bei hobby projekten hat man genug zeit das design gut hinzubekommen und dann braucht man nicht viel kommentare (denn immer wenn ich denke, dass ich hier ein kommentar bräuchte - dann schreib ich den code so um, dass er lesbar ist (einzige ausnahmen sind brute force optimierungen - aber die kommen sowieso nur alle heiligen zeiten einmal vor))

normalerweise sollte man auch in der arbeit ordentlichen code schreiben, aber irgendwie bin ich zu blöd dafür (liegt uU auch daran, dass wir nie konzeptionsbesprechungen haben - es heißt immer nur: "ich brauche feature X bis ende der woche", und da wirds halt viel pfusch :() (vielleicht hat ja da jemand einen tipp für mich?)

[Marc++us]

Original erstellt von Shade Of Mine:
(liegt uU auch daran, dass wir nie konzeptionsbesprechungen haben - es heißt immer nur: "ich brauche feature X bis ende der woche", und da wirds halt viel pfusch :() (vielleicht hat ja da jemand einen tipp für mich?)

~team_leader();

Das liegt nicht an wirklich an Dir. Es ist allerdings auch ein heiliger Wunsch an die Teamleitung, weil man in dieser Funktion so viel Scheiß zu erledigen hat, daß man kaum zur gemeinsamen Codebetreuung kommt. Ich denke mir, daß dies auch ein Grund ist warum eXtreme Programming auf Zweierteams setzt - man hat jemanden zum reden und diskutieren über das Programm, auch wenn der Teamleiter nicht da ist.

[Flow_cplus]

Also ich hab mal ein Projekt in einer Firma Programmiert, so ne kleine Schrittmotorsteuerung mit Ablaufscript für Versuchsaufbau.
Da hat das mit der Doku soweit auch geklappt, was aber daran lang, das ich nie ne 'Denkpause'(also längere Zeit unterbrochen) eingelegt hab und fast jeden Tag dran saß. So hab ich nie den Faden verloren, aber Daheim is solviel nebenher, Studium, Gitarre, Musik, Aufnehmen, Sport, Parties etc.. und wenn ich dann zum programmieren komm bin ich froh wenn ich dann nachts um drei wieder was geschafft hab. Dann geh ich meistens ins Bett und nicht zu dokumentieren !!
(Was dann zu eben oben beschriebenen Problem führt)

Gruß Flow

[malfunction]

Also ich kenne das Problem, dass man seinen eigenen Code nicht mehr so gut versteht, auch ziemlich gut. Ich hab nun schon den dritten Versuch eines gemeinsamen Projektes mit TheToast gestartet und beim zweiten Versuch wollte ich die Überreste des ersten Versuches benutzen. Das hat richtig lange gedauert bis ich da wieder halbwegs durchgestiegen bin.
Viel schlimmer ist es allerdings wenn man im betrunkenen Zustand programmieren will und sich dadurch nur den ganzen Sourcecode ruiniert. Das hatte ich ein paar mal und mache seitdem immer Sicherungskopien bevor ich angetrunken programmiere.

[2]

Das hatte ich ein paar mal und mache seitdem immer Sicherungskopien bevor ich angetrunken programmiere.

Wer programmiert auch schon im angetrunkenen Zustand?

Also betrunken Autofahren ist ja Ok, aber programmieren.? wow

[donay]

und wer denkt dann noch an sicherungskopien;-)

[malfunction]

Also RICHTIG betrunken bekomme ich da sowieso nichts mehr auf die Reihe, aber recht angetrunken geht's noch. Ich habe schon sehr oft gelesen, dass viele programmieren wenn sie stoned sind.
Ach ja, betrunken autofahren ist NICHT ok.

[Blackbird]

Das Ziel bestimmt (meistens) den Weg. Gibts einen Kunden, der für die Programme richtig bezahlt und auf absolute Termintreue drängt und jede Menge Anwälte hat, dann wird so richtig nach ISO 9000 usw. programmiert UND dokumentiert (besonders im Code). Ist's nur für mich alleine und ein kleines Programm - dann "vergesse" ich jeden Kommentar. Fällt mir bei so einer Arbeit eine gute (Programmier-)Idee ein, dann wird die auch dokumentiert (und nur die). Zwecks späterer Weiterverwendung.
Etwas Kommentar sollte aber immer sein. Das wird man spätestens dann einsehen, wenn man ausbilden muß oder Freunde um (Programmier-)Hilfe bitten. Da wird man froh sein, gut (und richtig) kommentierten Beispielcode zu haben. Außerdem kann man dann so schön "code (re)cycle" betreiben

Blackbird