[Tipps & Tricks] bad programming

[Raidenkk]

Und das lustige ist ja du kommst mit dem Code auch noch klar^^ das bringt mich immer wieder zum Staunen :D

[Virus]

Und das lustige ist ja du kommst mit dem Code auch noch klar^^ das bringt mich immer wieder zum Staunen :D

Der Beweis ist noch zu erbringen. StoneQuest jedenfalls reicht dazu (noch) nicht.

[BeRsErKeR]

Ich habe gerade festgestellt, meine längste Funktion hat etwa 2,8k Zeilen :D ( Ohne Kommentare. Kommentare hab ich ja vielleicht 10 oder so im ganzen Code )

Öhm ich hab ja auch schon leicht längliche Funktionen, aber bei mehr als 30 Zeilen sollten in der Regel die Alarmglocken leuten. Und 2,8k? Dann machst du definitiv was falsch. ^^

[Lynxeye]

Ich habe gerade festgestellt, meine längste Funktion hat etwa 2,8k Zeilen :D ( Ohne Kommentare. Kommentare hab ich ja vielleicht 10 oder so im ganzen Code )

Ich bin ja auch ein Verfechter von gern mal etwas längeren Funktionen, da man dadurch sehr schön die Übermodularisierung und die damit einher gehenden unüberschaubaren Callgraphen vermeiden kann, aber hier machst du definitiv etwas falsch. Das du das Ganze noch beherrschst liegt daran, dass du tagtäglich mit dem Code arbeitest und deine gesamte Codebase noch ganz gut in deinen Kopf passt.

Ich wünsche dir allerdings nicht, dass du in einem halben Jahr einen Bugfix an einer Stelle im Code machen musst, die du länger nicht mehr angesehen hast. Dann gehen nämlich die richtigen Probleme erst los. Wenn aus deinem Kopf einiges durch die natürliche Verdrängung heraus gefallen ist und du dich dann noch mal in den Code einarbeiten musst, wirst du dich verfluchen.

[Stefan Zerbst]

Ein spannender Thread, der aber ganz deutlich den gravierenden Unterschied zwischen Hobby-Projekt und kommerziellem Produktivcode zeigt :)

Just my 2 Cents aus der Sicht des beruflichen Software-Entwicklers in einem größeren Team an einer größeren Software:

Solche Makros wie das Zusammenschrumpfen von n Schleifen auf ein Makro würden bei uns kein Peer-Review überstehen. Warum? Ist ganz einfach, wer als C++ (oder Delphi, oder Pascal oder what ever) Entwickler angestellt ist, der kann C++. Wenn er drei Schleifen sieht weiß er was vor sich geht. Wenn er irgendein Makro mit 6, vermutlich noch kryptisch benamsten, Übergabeparametern sieht, dann weiß er nicht was dort vorgeht und muss sich das erst genau anschauen. Bessere Lesbarkeit des Code? Fehlanzeige.

Der nächste sieht das Makro, findet es geil aber es fehlt ihm noch eine Winzigkeit. Also kopiert er das Teil und haut aber noch einen Parameter xyz mit dazu weil er das braucht und das bestehende Makro nicht verändern möchte. Warte drei Monate und aus den drei Makros sind 10 geworden. Bessere Übersichtlichkeit? Fehlanzeige.

Nun zu den 2,5 k Codezeilen für eine Funktion. Auch das würde dir keiner für produktiven Code abnehmen. Der Grund dafür ist denkbar einfach, egal ob man objektorientiert oder funktionell programiert: Bei einer derart langen Funktion gibt es nur zwei Gründe für deren ausufernde Länge:

• Entweder ist sie historisch gewachsen, also mit der Zeit Zeile für Zeile. Dann sorgt aber jede Zeile Code mit an Sicherheit grenzernder Wahrscheinlichkeit dafür, dass sie immer spezialisierter wird und damit eigentlich auch nur genau für eine einzige aufrufende Stelle verwendet werden kann. Das bedeutet normalerweise auch, dass man innerhalb dieser 2,5k Zeilen Code etliche Dinge findet, die in anderen Funktionen analog redundant implementiert sind. Ein gutes Beispiel für Spaghetti-Code :)
• Die zweite Möglichkeit ist, dass die Methode von vornherein aberwitzig generell gehalten werden soll und Dutzende von verschiedensten Fällen, die wenig miteinander zu tun haben, mit einer Funktion erschlagen werden sollen.

Egal welcher der beiden Fälle zutreffend ist, beide sind gleichermaßen schädlich. Morgen hat ein anderer Programmierer die Aufgabe, diesen Code zu warten oder muss dort im Rahmen seiner eigenen Aufgaben etwas einbauen oder einen Bug fixen. Wie lange wird der wohl brauchen, um die 2,5 k Zeilen Code zu lesen und, vor allem, um sie zu verstehen und sinnvoll zu debuggen? Dann schaue mal in einen aktuellen Gehaltsspiegel für Software-Entwickler und rechne dir aus, was es deinen Chef kostet einen seiner Entwickler eine 2,5k Funktion zu debuggen oder dort Veränderungen vorzunehmen zu lassen im Vergleich zu einer 100 Zeilen Funktion auf die man das aktuelle Problem in vergleichsweise kurzer Zeit eingrenzen könnte.

Das ist nicht bös' oder mit erhobenem Zeigefinger gemeint. Gerade bei persönlichen Projekten zu Hause kann ja jeder tun was er möchte, und so lange dabei etwas lauffähiges rauskommt ist das umso beeindruckender :)

Aber sobald man beruflich mit der Programmierung zu tun hat gelten ganz andere Kriterien an denen "guter" Code gemessen wird, was immer mit "gut" gemeint ist. Bei kommerziellen Projekten verwächst sich anfangs "guter" (im Sinne von "schön designter") Code quasi in Zeitraffer zu einem historisch gewachsenen Wust an geschichteten Spaghetti die man quasi jährlich groß aufräumen muss damit es wartbar bleibt.

Das ausschlaggebende Kriterium für "guten" Code dabei ist eigentlich hauptsächlich, dass ein anderer Entwickler sich in kürzester Zeit halbwegs in den betroffenen Sourcen zurecht findet und dort auch produktive Arbeit erledigen kann. Und da ist es allemal besser sich an den Sprachstandard zu halten als auf unique Makros zu setzen, ebenso wie es besser ist, den Code so sinnvoll in Objekte mit Methoden oder Funktionen zu unterteilen, dass eine Funktion aus dem Aufrufen von logisch benamsten Unterfunktionen und nicht aus Tausenden von tatsächlichen Operationen besteht.

So, genug subjektive Weisheiten für heute :mrgreen:

Ciao,
Stefan

[joggel]

Bei kommerziellen Projekten verwächst sich anfangs "guter" (im Sinne von "schön designter") Code quasi in Zeitraffer zu einem historisch gewachsenen Wust an geschichteten Spaghetti die man quasi jährlich groß aufräumen muss damit es wartbar bleibt.

Wow!! Wenn Du wüsstest wie 1000%ig recht du damit hast!!
Bekomme ich gerade zu spühren!
Ein grosses Projekt bei denen mehrere daran arbeiten, sollte öfters "aufgeräumt" und so verständlich wie möglich geschrieben sein... Selbst ich als Autor habe da manchmal Probleme _ALLES_ zu verstehen.

Aber das ist auch nur eine subjektive Meinung/Erfahrung!

[antisteo]

Solche Makros wie das Zusammenschrumpfen von n Schleifen auf ein Makro würden bei uns kein Peer-Review überstehen. Warum?

Ja, warum auch. Zudo arbeitet doch alleine :P

Nun zu den 2,5 k Codezeilen für eine Funktion. Auch das würde dir keiner für produktiven Code abnehmen. Der Grund dafür ist denkbar einfach, egal ob man objektorientiert oder funktionell programiert: Bei einer derart langen Funktion gibt es nur zwei Gründe für deren ausufernde Länge:

• Entweder ist sie historisch gewachsen, also mit der Zeit Zeile für Zeile. Dann sorgt aber jede Zeile Code mit an Sicherheit grenzernder Wahrscheinlichkeit dafür, dass sie immer spezialisierter wird und damit eigentlich auch nur genau für eine einzige aufrufende Stelle verwendet werden kann. Das bedeutet normalerweise auch, dass man innerhalb dieser 2,5k Zeilen Code etliche Dinge findet, die in anderen Funktionen analog redundant implementiert sind. Ein gutes Beispiel für Spaghetti-Code :)
• Die zweite Möglichkeit ist, dass die Methode von vornherein aberwitzig generell gehalten werden soll und Dutzende von verschiedensten Fällen, die wenig miteinander zu tun haben, mit einer Funktion erschlagen werden sollen.

Oder die Funktion enthält ein großes Switch-Case, welches sich nun mal nicht vermeiden lässt. Selbst wenn man den Inhalt der einzelnen Fälle in Funktionen ausgelagert ist, würde man trotzdem auf die Zeilenzahl kommen, weil man z.B. noch Parameter aufbereiten muss.

That's just my two Senf.

[Zudomon]

Ich werde mich auch in Zukunft blitzschnell in meinem Code zurecht finden. Da ich nicht immer sämtliches neu programmiere, arbeite ich ja auch mit meinem alten code. Und der ist auch schon bis zu 5 Jahre alt... aber auch in Projekten, die noch wesentlich älter sind, weiß ich, was ich da gemacht habe. Und das ohne Kommentare, denn die versauen mir alles. Ich kann auch überhaupt nicht mit breitgefächerten Code umgehen, weil ich dann anfangen müsste, wenn ich irgendwas suche, den Code zu lesen und das kostet Zeit. Mir ist aufgefallen, dass mein Code an jeder Stelle ein einzigartiges Bild ergibt. Ich brauch nur die ungefähre Struktur zu sehen, und schon weiß ich, was ich da gemacht wurde. Klar muss ich dann auch nochmal etwas genauer hinsehen manchmal, aber im groben trifft das auf jeden Fall zu.
Im Grunde ist mein Code ja auch in meinem Kopf gespiegelt. Ich kann diesen begrenzt auch debuggen, ohne ihn zu sehen, weil ich ihn ja quasi im Kopf habe.
Und da ist auch das fatale, weswegen ich absolut nicht im Team arbeiten kann, denn sobald jemand an meinem Code rumbaut, ist das nicht mehr synchronisiert... das Codebild ändert sich, ohne das ich davon weiß und ich finde mich nicht mehr zurecht.

Was die lange funktion angeht, ich denke nicht, dass die sehr redundant geschrieben ist... es wiederholen sich dort zwar einige Stellen, aber auch das ist hier eher gewollt und dient der Übersichtlichkeit... denn in dieser Funktion sind 54 Shader implementiert. Bei dem der der längste Shader bis 480 Zeilen umfasst. Hier hatte ich einen Auszug gepostet (in der ersten Codebox). Nicht wundern, wenn nicht alles perfekt eingerückt ist... darauf lege ich nicht immer so großen Wert... vor allem, wenn es mal schnell dahin gerotzt ist.

Ich finde es immer so lustig, wenn andere mir prophezeien, dass ich nicht durch meinen Code durchsteigen werde oder ähnliches (auch wenn ich den Monate nicht gesehen habe, klappt das Problemlos). Ihr kennt mich ja nicht, und nur weil ihr selbst nicht in der Lage dazu seit, immer auf andere zu schließen und über einen Kamm zu scheren, kann dies ja schnell zu Fehleinschätzungen führen.

PS: Was mir auch mal aufgefallen ist. Das ich fremden Code kaum lesen kann. Selbst wenn ich weiß, was da so vorgeht.

[Zudomon]

Noch ein kleiner Nachtrag aus dem Kuriosenkabinett:
Mein Objekt, was zum Sound laden und abspielen zuständig ist, zeichnet auch Buchstaben auf Texturen :lol:

[Zudomon]

Oder die Funktion enthält ein großes Switch-Case, welches sich nun mal nicht vermeiden lässt. Selbst wenn man den Inhalt der einzelnen Fälle in Funktionen ausgelagert ist, würde man trotzdem auf die Zeilenzahl kommen, weil man z.B. noch Parameter aufbereiten muss.

Oh sorry, dich hatte ich ganz übersehen... ( vielleicht weil wir ziemlich zeitgleich gepostet haben )
Aber du hast recht. Es handelt sich eben um einen SwitchCase, bzw. in einem solch großen Fall verwende ich einfach ein großes IF... finde ich übersichtlicher.
Und so schlimm sind solche großen Funktionen wirklich nicht, weil man sich die dann noch schön mit Regions zusammenklappen könnte.
Aber wenn ich mal anfange, die ganzen Daten auszulagern, dann wird der ganze Code wohl rapide zusammenschrumpfen... ich freu mich schon drauf.
Vielleicht hat ja das finale Stonequest dann <20k Zeilen, fände ich Wahnsinn :D

[Stefan Zerbst]

Und da ist auch das fatale, weswegen ich absolut nicht im Team arbeiten kann, denn sobald jemand an meinem Code rumbaut, ist das nicht mehr synchronisiert... das Codebild ändert sich, ohne das ich davon weiß und ich finde mich nicht mehr zurecht.

Exakt, und das war das einzige was ich sagen wollte. Wenn jemand allein für sich an einem Projekt arbeitet soll er das so tun, wie es für ihn am besten ist. Aber sätestens wenn zwei Leute an demselben Projekt arbeiten geht das so gar nicht.

Und bei der langen Funktion hätte ich die Shader trotzdem in eine eigene Datei oder ein include File ausgelagert. Das fände ich deutlich übersichtlicher. Aber insgesamt zählt das dann ja nicht mehr als 2,5k Funktion wenn da nur lange Shader Strings drin sind. Was das allerdings für das Debuggen der Shader bedeutet wage ich gar nicht erst zu überlegen ;)

Ich finde es immer so lustig, wenn andere mir prophezeien, dass ich nicht durch meinen Code durchsteigen werde oder ähnliches (auch wenn ich den Monate nicht gesehen habe, klappt das Problemlos). Ihr kennt mich ja nicht, und nur weil ihr selbst nicht in der Lage dazu seit, immer auf andere zu schließen und über einen Kamm zu scheren, kann dies ja schnell zu Fehleinschätzungen führen.

Wollte ich nicht und habe ich, glaube ich, auch nicht getan :) Mir ging es nur darum, den Unterschied zwischen dem 1-Mann und dem n-Männer Team mit n > 1 herauszustellen. Falls hier jemand mitliest, der später mal beruflich im Bereich der Softwareentwicklung arbeiten möchte dann sollte der seine persönliche Arbeitsweise gleich dahingehend analysieren, ob er das leisten kann. Meine Definition von "gutem Code" oben kann ich noch etwas verallgemeinern und sagen, dass kommerziell produktiv "guter Code" derjenige ist, welcher teamfähig ist. Dann wird offensichtlich, warum sich das nicht unbedingt mit der Definition von "gutem Code" eines Individuums decken muss ;)

Ciao,
Stefan

[Stefan Zerbst]

Aber du hast recht. Es handelt sich eben um einen SwitchCase, bzw. in einem solch großen Fall verwende ich einfach ein großes IF... finde ich übersichtlicher.

Einen kleinen Seitenhieb kann ich mir da aber nicht verkneifen: switches sind sicherer, weil man keinen Fall übersehen kann wenn man mit enums und Compiler-Warnungen arbeitet. Auch hier gilt: Wenn du das nur an einer Stelle tust dann ist das nicht ganz so entscheidend. Aber wenn du ein größeres Projekt aus mehreren Bibliotheken hast, an denen enums an Dutzenden Stellen ausgewertet werden, dann hilft dir ein switch extrem dabei, wenn du die enum erweiterst oder reduzierst. Die Compiler-Warnung bei nicht behandelten cases retten dich davor, das tägliche Build zu zerstören. Klar kompiliert es mit if Abfragen besser, aber dann wirst du nie wissen, ob du wirklich überall alle Fälle berücksichtigt hast.

Ciao,
Stefan

[Zudomon]

Wollte ich nicht und habe ich, glaube ich, auch nicht getan :)

Ich meine, Liynxeye hatte das gesagt. War also garnicht auf dich bezogen. Ich weiß, dass du da zwischen ein-Mann und mehr-Mann Teams hineweisen wolltest. Das habe ich hier im Thread auch schon desöfteren getan. Denn solange man alleine macht ist es egal... und wenn man zu mehreren macht, dann sollte man eben diese ganzen Dinge beachten, damit es eben im Team klappt.
Aber naja, für sowas bin ich nicht geeignet.

Die Compiler-Warnung bei nicht behandelten cases retten dich davor, das tägliche Build zu zerstören. Klar kompiliert es mit if Abfragen besser, aber dann wirst du nie wissen, ob du wirklich überall alle Fälle berücksichtigt hast.

Man merkt doch, ob alles so läuft, wie es soll, oder eben nicht. Das tägliche Build? Das versteh ich nicht.

[kimmi]

@Stafan Zerbst:
Du scheinst mit deiner Firma Glück gehabt zu haben. ich kann mit nun mehr 10 Jahren Berufserfahrung sagen, dass faktisch alle Legacy Codesbases, die ich warten durfte, in der Regel wahre Drahtverhaue waren, an die sich keiner mehr herangetraut hat ( außer mir, weil das mein neuer Job war ). So etwas habe ich mittlerweile in C, C++, F90, F77, Python, PHP, Java, C# bzw. .Net und Visual Basic gesehen.

Gerade kritische unter Zeitdruck entstandende Subsysteme sind sehr anfällig für so etwas. Dazu gibt es nicht selten so etwas wie Wissensmonopole, die von den Entwicklern gehütet werden wie der heilige Grahl. Ein Freelancer hat mir dazu mal eine witzige weil wahre Begebenheit geschildert: Bekannte bauen Systeme gern verwirrend, damit sie über Jahre hinweg noch als Berater tätig sein können -> Jobgarant. Code-Reviews helfen da nur bedingt, wenn der Zeitplan mal wieder auf Kante genäht wurde und keine Zeit für wirkliche Änderungen bleibt. Oder man hat zu einem speziellen Thema wie Mathlab nur einen Spezialisten in der Firma, so dass keiner wirklich Code-Reviews auf Augenhöhe durchführen kann.

Glücklicherweise geht es auch anders und ich befinde mich auch gerade in der glücklichen Lage, keine solch bösen Codewüsten zu beackern. Aber ein Großteil des Codes, der die heutige Welt am Laufen hält, ist unter Garantie sehr sehr alt, sehr lange gewachsen und sieht aus wie Knüppel auf dem Kopf. Deswegen rate ich wirklich jedem von so etwa ab. Und hier im Thread haben wir mit Zudomon mal wieder ein Beispiel dafür, wie jemand an seiner Arbeitsweise festhält. Das geht natürlich, hat in der Vergangenheit aber schon sehr sehr oft Probleme wie die oben geschilderten verursacht, gerät sein Baby in die freie Wildbahn.

Geschichte ist halt die Wiederholung von bereits gemachten Fehlern :) ...

Gruß Kimmi

[kimmi]

...

Die Compiler-Warnung bei nicht behandelten cases retten dich davor, das tägliche Build zu zerstören. Klar kompiliert es mit if Abfragen besser, aber dann wirst du nie wissen, ob du wirklich überall alle Fälle berücksichtigt hast.

Man merkt doch, ob alles so läuft, wie es soll, oder eben nicht. Das tägliche Build? Das versteh ich nicht.

Wenn du die Zeit hast, bei jeder Änderung alles zu testen: ja, dann merkt man das. So etwas geht in der Regel aber nur, wenn man automatische Tests laufen lässt, weil du sonst unter Garantier irgend ein kleines aber etscheidendes Feature mit dem Hintern wieder umreisst, während du woanders am Werkeln bist. Und gerade lange If-Abfragen oder große Switch-Case-Anwendungen sind für so etwas recht gute Kandidaten.

Gruß Kimmi

P.S.: Kennst du die SOLID-Prinzipien?

[Stefan Zerbst]

Man merkt doch, ob alles so läuft, wie es soll, oder eben nicht. Das tägliche Build? Das versteh ich nicht.

Also ... wenn du tatsächlich "merkst" ob alles noch läuft, dann hast du entweder einen großen Kopf oder wenig Anwendungsfälle der Software. Natürlich merkt man nicht, ob alles noch läuft, weil man dazu alles ausprobieren müsste was eine soeben veränderte Codestelle verwendet. Das wiederum setzt voraus, dass man alle Funktionalitäten der Software mit ihrem Ablaufgraph durch den Source kennt. Und das wiederum ist bei einer größeren Software und Teamarbeit unmöglich.

Das tägliche Build: Wenn ein größeres Team an einer größeren Software arbeitet, dann muss das natürlich alles zusammen laufen. Jeder Entwickler checkt also seine Änderungen per SVN oder ähnlichem in eine Versionskontrolle ein. Der Source Code wird dann zentral mindestens einmal, i.d.R. aber mehrfach täglich kompiliert. Sprich: das tägliche Build wird erzeugt. Wenn man mit seinem Code also einen Compilerfehler erzeugt, und zwar in Modulen an denen man nicht selber gearbeitet hat, die aber zum Beispiel auch eine enum verwendet die man eben geändert und nach allen deren Verwendungen im gesamten Source Code nur schlampig gesucht hat, dann fällt das erst beim zentralen Kompilieren auf. Und damit hast du das tägliche Build kaputt gemacht und deine Kollegen geärgert da deren Änderungen dann an dem Tag erst später oder gar nicht in der gesamten Software zur Verfügung stehen.

Und bei größeren Software Projekten, und wenn die Entwicklergruppe gleichzeitig auf mehreren Betriebssystemen unterwegs ist, dann rechnet man die Kompiliertzeit in Stunden und nicht mehr in Minuten. Also mal eben schnell Compilefehler fixen und neu anstarten ist nicht. :oops:

Du scheinst mit deiner Firma Glück gehabt zu haben.

Jap :) Nach jedem Major Release, bevor der nächste angegangen wird, gibt es normalerweise eine Refactoring-Phase in der man die größten Drahtverhaue entwirren kann damit der Code wieder wartbarer wird / bleibt. Und so lange die Firma weiß, dass sie in ihren Mitarbeitern das größte Kapital hat brauch tman auch nicht so zu programmieren, dass man der einzige Mensch auf der Welt ist der so etwas warten kann. Auch dazu sind Peer-Reviews vor dem SVN Commit gut, weil der Peer dann mit in der Verantwortung ist nur wartbaren Code in die Produktivversion zu lassen :mrgreen:

Ciao,
Stefan

[Stefan Zerbst]

... weil du sonst unter Garantie irgend ein kleines aber etscheidendes Feature mit dem Hintern wieder umreisst, während du woanders am Werkeln bist

Zu schön, das musste ich einfach noch mal zitieren :lol:

Wie oft stand man schon staunend vor Features die man eben gerade kaputt gemacht hat und sagt sich:

• Das kann meine Änderung doch gar nicht bewirkt haben. ... oder
• Ich war das nicht ... oder doch?

[Chromanoid]

Am schnellsten passiert sowas, wenn man sich dann auch noch um mehrere Branches kümmern muss. Wenn man sich dann nicht mehr sicher ist, in welchem man was verändert hat, dann kommt richtig Freude auf... Ich setze jetzt natürlich voraus, dass man die Änderungen nur ungenügend dokumentiert hat... Naja wann kommt das schon mal vor? :)

[kimmi]

Erwähnte ich, wie toll automatische Tests sind, die einem bei so etwas helfen?

Gruß Kimmi

[Chromanoid]

Ja, automatisierte Tests, die wären schön :). Sowas braucht leider seine Zeit, wenn vorher ohne Tests entwickelt wurde...

[antisteo]

SVN, SVN, SVN....


Branchorientierte Versionskontrollsysteme ftw.
Da kann niemand dem anderen seinen Code kaputt machen und man kann immer komplette Features testen beim jeweiligen Merge.

[Chromanoid]

Naja mergen kann auch ziemlich eklig werden... Es gibt da nicht selten Unannehmlichkeiten, wenn man verschiedene Versionen gleichzeitig pflegen und individualisieren muss.

[Lynxeye]

SVN, SVN, SVN....


Branchorientierte Versionskontrollsysteme ftw.
Da kann niemand dem anderen seinen Code kaputt machen und man kann immer komplette Features testen beim jeweiligen Merge.

Ob ich nun sofort beim einchecken eines Commits den DailyBuild kaputt mache oder erst beim mergen eines Branches zerstöre kommt aufs gleiche raus. Außer das ich beim mergen vll. noch mehr Aufwand habe, da ich erst rausfinden muss mit welchem meiner vielen Commits ich etwas kaputt gemacht habe.

Bitte nicht als Statement gegen Branches in der Versionskontrolle verstehen, die sind wirklich ein tolles Werkzeug, aber definitiv nicht das Allheilmittel für Teamarbeit an einem Projekt.

[kimmi]

Continuous Integration ist da eine mögliche Antwort. Mit Unittests, Jenkins und Code-Reviews geht das schon ganz gut.

Gruß Kimmi

[antisteo]

SVN, SVN, SVN....


Branchorientierte Versionskontrollsysteme ftw.
Da kann niemand dem anderen seinen Code kaputt machen und man kann immer komplette Features testen beim jeweiligen Merge.

Ob ich nun sofort beim einchecken eines Commits den DailyBuild kaputt mache oder erst beim mergen eines Branches zerstöre kommt aufs gleiche raus.

Das auch nicht wirklich, da meine Commits viel feingranularer sind und Branches dagegen größere Features. Die letzten Commits eines Branches sind dann Dinge a la "Fix regression...". Außerdem lese ich bei jedem Merge den reingemergten Code durch und erkenne so viel besser eventuelle Probleme, breche vielleicht sogar den Merge ab, während ich bei SVN einzig und allein die Möglichkeit des Backout habe.

[Chromanoid]

^^

[CodingCat]

[kaiserludi]

Hier sind auch ein paar nette Tipps bei:
http://p-nand-q.com/humor/obfuscating_c_c++.html

[Zudomon]

Hier sind auch ein paar nette Tipps bei:
http://p-nand-q.com/humor/obfuscating_c_c++.html

Oh wie geil! Da ist es richtig ärgerlich, dass man keinen Job hat, wo man das anwenden könnte! :lol:

[BeRsErKeR]

Dazu gibt es nicht selten so etwas wie Wissensmonopole, die von den Entwicklern gehütet werden wie der heilige Grahl. Ein Freelancer hat mir dazu mal eine witzige weil wahre Begebenheit geschildert: Bekannte bauen Systeme gern verwirrend, damit sie über Jahre hinweg noch als Berater tätig sein können -> Jobgarant. Code-Reviews helfen da nur bedingt, wenn der Zeitplan mal wieder auf Kante genäht wurde und keine Zeit für wirkliche Änderungen bleibt. Oder man hat zu einem speziellen Thema wie Mathlab nur einen Spezialisten in der Firma, so dass keiner wirklich Code-Reviews auf Augenhöhe durchführen kann.

[Offtopic]Das ist ein großes Problem, nicht nur in der Softwareentwicklung. Es gibt eine Menge Leute, die so tun als wären sie unentbehrlich oder verrichten Wunder und dabei sind sie einfach nur faul. Mir ist das bei meinem neuen Arbeitgeber aufgefallen. Einer der größten Konzerne Deutschlands. Da sitzen hunderte Leute und arbeiten an etwas, was man mit ein wenig Organisation mit 2 Arbeitern in der gleichen Zeit schafft. Die kriegen ein Schweinegeld, arbeiten 4 Stunden am Tag und sind nur am Jammern. Ich hab als Neuling da in der Hälfte der Zeit das 7-fache geschafft ohne jegliche Vorkenntnisse. Und das ist nun wahrlich keine Raketenwissenschaft. Da fragt man sich echt was hier im Lande los ist. Ich kannte das vorher nicht so. Da war für mich ein Arbeitstag von 8 bis 20 Uhr normal und wenn ich jetzt um 8 auf Arbeit bin, bin ich allein und nach 17 Uhr auch wieder. Was ich allerdings eigentlich sagen wollte ist, dass die Leute halt alle so tun als wäre die Arbeit extrem schwierig und anstrengend und kriegen daher viel Kohle. Prinzipiell sehr clever aber für sowas bin ich einfach zu ehrlich.[/Offtopic]


Zum Thema Riesen-Switch-Block: Damit hab ich auch schon oft was sehr längliches fabriziert, z.B. bei Scriptinterpretern, allerdings kann man da in der Regel auch maps mit Funktionspointern nutzen oder wenigstens den Inhalt der case-Blöcke in Funktionen auslagern. Regions kann man ja eventuell nutzen, aber nicht jeder arbeitet mit IDEs und bei großen switch-Blöcken geht auch damit irgendwann die Übersicht flöten. 2,8k Zeilen Code würde ich nicht mal in einer Datei unterbringen. Die halte ich nach Möglichkeit auch recht klein genau wie Klassen. Auch mit dem Gedanken eines Soloprojekts im Hinterkopf seh ich das kritisch. Ich hatte auch schon Monsterprojekte und habe auch noch 2 am laufen. Wenn man da mal 1-2 Monate nicht mehr reinguckt hat man ganz schön zu schlucken wenn das schlecht strukturiert ist oder einen der Code erschlägt. Daran bin ich schon oft gescheitert bzw. habe dadurch temporär oder gänzlich die Lust verloren am Projekt weiterzuarbeiten.