Diskussion Lust auf Gammelcode?

Mat

Aktives Mitglied
Lust, mal ab und an zusammen Code durchzugehen (egal von wem)? Wir könnten uns gegenseitig reviewen.

Ich musste daran denken, weil ich momentan an einem Uniprojekt arbeite.. und je näher der Abgabetermin rückt, desto HÄSSLICHER wird der Code. Normalerweise versteht man seinen eigenen Code erst ein paar Monate später nicht mehr und nicht schon während des Schreibens. :p

Aber so ist das, wenn man Code im Halbschlaf oder ohne Schlaf hinklatscht. Am darauffolgenden Morgen sehe ich dann den Salat und würde am liebsten nur noch Refactoring machen, komme aber aus Zeitmangel nicht dazu. Stattdessen wird der Code weiterverwendet, damit das Projekt fertig wird. Weil Uniprojekte bei mir gerne mal besonders am Anfang sehr explorativ sind und teilweise auch nie den Prototyp-Status verlassen, fällt es mir schwer, sinnvolle Architekturentscheidungen zu treffen.

Habe mir auch meinen anderen alten Code angeschaut und es gibt da so einige Uniprojekte, die nicht sehr gut geworden sind. Und da dachte ich mir: das könnte man doch hier zur Diskussion reinstellen, dann lerne ich noch was daraus. Und vielleicht andere auch.

Ich würde dann versuchen nur Unicode zu posten, bei dem ich die Komponenten isolieren und die Aufgabenstellungen generalisieren kann, damit das nicht zu einer Lösungssammlung wird (oder Code aus Hobbyprojekten posten).

Was haltet ihr davon, besteht Interesse?
 
Ich find die Idee auch ziemlich cool! Gerade Projekte die mal nicht nur Hausaufgaben sind fänd ich interessant, so könnte man auch mal mehr über Tooling, Projektorganisationen und so reden(gerade bei C/C++ ist das ein großes Thema).

MfG
 
Da ich mich damit ziemlich viel befasst habe frag ich hier einfach mal, denn ich denke das könnte helfen, Code etwas weniger gammelig zu machen : besteht Interesse an einer kleinen Übersicht "Wie starte ich ein C/C++-Projekt?" mit Schwerpunkt auf Tooling, Codeorganisation etc.? Dann würde ich dazu mal eine kleine Resource zusammen schreiben, da sehe ich leider regelmäßig sehr viel sehr schlimm schief gehen(das fängt an mit der Abwesenheit von Tests, über ein Projektlayout aus den frühen 70ern, bis hin zu git mit nur einem Branch).

MfG
 
je näher der Abgabetermin rückt, desto HÄSSLICHER wird der Code.

Das der Grund warum ich keine Termine mache. Es ist grausam.

Normalerweise versteht man seinen eigenen Code erst ein paar Monate später nicht mehr und nicht schon während des Schreibens.

Öhh.. LOL Jane. Das kommt drauf an.
Ich hab die doofe angewohnheit einfach anzufangen, der rest entwickelt sich dann.
wenn ich gelegentlich, sehr selten, ab und zu mal in nem lichten moment nicht mehr drüber nachdenke was ich schreibe dann kann ich das schon ne sekunde später nur noch schwerer nachvollziehen. Ab irgend nem Punkt ändert sich die denkweise und dann wird das danach echt hart.

könnte man doch hier zur Diskussion reinstellen, dann lerne ich noch was daraus. Und vielleicht andere auch.

Kann man machen find ich gut. Aber lernen... Ich finde das ist gewöhnungssache.
Aber Tips sind gut.

Projektorganisationen und so reden(gerade bei C/C++ ist das ein großes Thema).

Bin ich absolut dafür. Sprache ist mir wurscht.

Codeorganisation etc.?

Gibts da nicht schon "Empfehlungen" ?

Auch Projektname, command wahl. Argumente usw könnte man ja mal im auge behalten.
 
Ja, natürlich gibt es diese Empfehlungen schon, und von viel schlaueren Menschen als mir. Also ja, für dioe die das wissen ist da nichts neues bei, nehme ich an. Das Problem ist : der Regelfall ist, dass die Menschen es nicht wissen. Kurse und Bücher ignorieren das komplett, im schulischen Teil einer Ausbildung kommt es nicht oder nicht hinreichend vor, im Informatikstudium auch kaum, wenn man nicht spezifisch so die Wahlpflichtteile gestaltet - und in der "Industrie" kriegen die es ja selbst nicht einmal einigermaßen hin. Daher glaub ich schon dass es wichtig ist, für sowas etwas offensiver ein Bewusstsein zu schaffen^^
 
Gebe ich dir Recht. Und als Hobbyist lernt man so etwas gar nicht. Erst durch Schmerz. Ich war bspw. auch lange Zeit der Meinung dass Versionierung nur was für Projekte ist an denen ein Team arbeitet. (Gut, für Code mit ein paar Zeilen braucht man das letztlich nicht ;)) Aber tatsächlich ist das auch für Einzelkämpfer komfortabel. Ich bin schon oft in die Verlegenheit gekommen, dass ich erst nach einiger Zeit gemerkt habe irgendwo einen Bug eingebaut zu haben der nicht gleich offensichtlich war. Dann zu einem Status x zurückzurudern, geht ohne vernünftige Versionierung nicht.
 
Bedauerlicherweise kann man das nicht an Hobbyisten und ihrem mangelnden Professionalismus fest machen. Ich hab das alles als Hobby gelernt :p Und außerdem muss ich sehr zu meinem Leidwesen zugeben: den erträglichsten Code den ich so gesehen habe habe ich immer bei im wesentlichen als Hobby gepflegten Open Source Projekten gesehen. Ich warte immernoch darauf, dass ich mal eine Firma sehe, die die Standards erfüllt, die ich an meine Hobbyprojekte anlegen würde ;) Im Regelfall ist das gerade bei Firmen ein absolutes Trauerspiel. Bei großen Firmen ist es oft etwas besser, aber selten viel besser als bei irgendwelchen kleinen Klitschen. Meine Hypothese ist, dass würden Softwarehersteller für grobe Fahrlässigkeit haften 95% davon innerhalb eines Jahres durch die Schadensersatzkosten pleite wären...

Und das fängt ja schon bei ganz banalen Sachen an : baut das Projekt mit angemessenen Warnings ohne Compilerwarnungen? Werden Sanitizer benutzt und sind die Sanitizer-Checks erfolgreich? Findet sinnvolles Testen im nötigen Umfang statt? Wird die Crypto angemessen verwendet? Sind wenigstens die offensichtlichsten Sicherheitsstandards erfüllt(Ausschließen von SQL-Injections, Ausschluss von Formatstring-Angriffen, korrektes Salten und Hashen der Passwörter, Nutzung von Stack-Protektoren, Reproduzierbare Builds...)?
Das wäre alles kein Hexenwerk und würde viel helfen.
 
Zurück
Oben Unten