An sich selber scheitern :-)
-
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.
-
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.
-
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?)
-
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.
-
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
-
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.
-
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
-
und wer denkt dann noch an sicherungskopien;-)
-
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.
-
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