Was war euer "schwerstes" Project?

[gack]

bitte sidewinder helfe mirrrrrrrrrr

[coolio]

howdy kumpel,
ich bin nicht so ein alter programmier haudegen aber mein erstes groesseres sache war damals eine kuenstliche intelligence fuer ein quake 3 basiertes computer spiel

mfg,
coolio

[frosty]

Häää!

Du kannst Dinge aus Linux nicht unter Win lesen?
Das habe ich ja noch nie gehört.

Und wieso nicht in Linux programmieren? Ist wenigstens ein OS das läuft

Ach ja, zum Thema: mein größtes Projekt war eine Bibliotheksverwaltung in Java.
Im Moment arbeite ich an einen Netzwerksimulator zur Entwicklung von Realtime-Ethernetkomponenten und den entsprechenden Algorithmen.

[SideWinder]

@frosty: Die IC läuft unter Linux nicht, ist eine Kapselung des Konsolen-Teils der WinAPI

@gack: Ließ dir mal Getting Started durch bzw. drucks aus, wenn du das alles hinkreigst lade dir die Sourcen und von den Demos Mover + Tech, fertig. Wenn du Getting Started nicht verstehst ließ die Seite für Programmieranfänger und hol dir alles wovon dort die Rede ist.

MfG SideWinder

[Michael E.]

Mein schwerstes Projekt ist mein jetziges: Ein bzip2-Packer. Dabei sind die Algorithmen nicht das schwere, sondern die Kompatibilität, denn Julian Seward hat es nicht für nötig zu halten, irgendwie mal die Dateistruktur festzuhalten. Jetzt kann ich mich durch übles C wurschteln.

[frosty]

Ok, wenn man unbedingt so ne IC benutzen will und nict die mächtige BASH?

[ness]

Mein schwerstes projekt...
hm...
naja, der multidispatcher war net ganz einfach
Überhaupt, an so template-spielereien kann man ewigkeiten sitzen (hab sogar maln debugging-framework entwickelt :D).
Naja, Hurd is auch nicht ganz billig. Wer schon mal mit virtuellen und physischen adressen über mehrere adressräume hinweg gearbeitet hat (stichwort programmstart), weiß was ich meine.

[BF_31]

Ich habe oft Projekte angefangen aber wieder verworfen. Das größte was ich bisher beendet hatte war ein Farbauswahl-Programm mit allen nur erdenklichen Features, nutze ich auch heute selbst noch. Finde wirklich das das sehr praktisch ist

Und dann mein aktuelles Projekt wird wohl mein größtes werden und ist es auch jetzt schon. Aber diesmal in PHP. Ich programmiere seit ca. 2 Wochen an einer eigenen Board-Software, ich bin auch schon soweit das der normale Board-Alltag funktioniert, jetzt kommen noch die ganzen Sonderfunktionen und Extras, und dann kann Version 1.0 veröffentlicht werden

[SideWinder]

@BF_31: Veröffentliche das doch bei Gelegenheit mal, ich hab auch mal ein privates Forum begonnen und kann Anregungen gebrauchen.

MfG SideWinder

[Gregor@Home]

Gregor schrieb:

Ich bin noch mit kleineren Programmen beschäftigt. Mein Bildverarbeitungsprogramm hat momentan 5836 Codezeilen (7669 mit Komentaren,...). Allerdings kann das Programm noch nicht sehr viel! ...und ich programmiere auch sehr selten daran herum. Äußerlich betrachtet hat die GUI etwas mehr als 10 Dialoge und ähnlich viele verschiedene Dinge kann man mit Bildern machen. Letztendlich natürlich viel mehr, da man bei jedem Dialog ja ganz verschiedene Dinge einstellen kann.

Hui, das ist ja schon lange her. Das Projekt da ist damals noch so auf 10000-12000 Codezeilen angewachsen, dann habe ich aber die Lust daran verloren und inzwischen arbeite ich an einem Nachfolgeprojekt mit ähnlichem Thema.

Warum habe ich damals die Lust daran verloren?

Naja, es gab da einige Dinge im Design des Programms, die mich immer mehr gestört hatten. Irgendwann habe ich dann eingesehen, dass ich das alte Projekt wegwerfen sollte und ein neues Projekt anfangen sollte, bei dem ich von Anfang an alles besser mache. Ich bin mit meinem aktuellen Projekt inzwischen zwar auch nicht mehr so ganz zufrieden, was das Design betrifft, aber ich habe durchaus aus meinen Fehlern damals gelernt und bin schon glücklicher mit dem aktuellen Design. Wahrscheinlich ist es so, wie volkard letzt mal gesagt hat: Man muss alles dreimal schreiben, weil man beim ersten mal noch nicht so viel weiß, wie man beim zweiten mal weiß und man beim zweiten mal auch noch nicht alles weiß. Bei mir kamen/kommen da neben den inhaltlichen Dingen (Bildverarbeitung ist ein sehr komplexes Thema, bei dem nicht sofort alle internen Beziehungen zwischen Algorithmen, Strukturen usw. klar sind) auch noch Aspekte des Programmdesigns hinzu, von dem ich damals sicherlich noch sehr viel weniger Ahnung hatte als heute. Wobei es heute sicherlich weiterhin viele Dinge gibt, die ich diesbezüglich falsch mache.

An den, der den Thread aufgewärmt hat und traurig darüber ist, dass seine Programme so klein sind:

Das ist eine Frage der Übung. Ich habe auch mit viel kleineren Programmen angefangen und heutzutage sind meine Projekte aus meiner Sicht vielleicht etwas größer, aber eigentlich immer noch klein. Ich kann dir nur empfehlen, immer weiter zu programmieren und dabei aus deinen Fehlern zu lernen. Dann wirst du mit der Zeit auch größere Programme schreiben. Und die Grenze, bei der du nicht mehr mit dem Programm umgehen kannst und es nicht weiter erweitern kannst oder willst und es weiter warten kannst oder willst, wird sich immer weiter nach oben verschieben. Bei mir gab es bei dem alten Programm auch so eine Grenze bei einer Größe von etwa 10000-12000 Zeilen bzw. etwa 200 Klassen. Ich bin mir sicher, dass diese Grenze bei dem neuen Projekt deutlich höher liegen wird.

...und neben der Übung durch Programmieren solltest du am Besten auch viel in diesem Bereich lesen, für neue Ideen offen sein und auch den Dialog bezüglich dieser Dinge suchen. Zum Beispiel in einem Forum wie diesem hier. Oft kommen doch gute Ideen von anderen Leuten, die einen weiterbringen.

[c.rackwitz]

eines meiner programme hat gerade mal 160 zeilen c und wird taeglich von mir verwendet. es ist ein kleines schnelles tool mit ziemlich simpler, schoener und maechtiger logik.
dann hab ich noch einen crond clon fuer windows geschrieben, der auf 500 zeilen kommt.

eigentlich sind alle meine konsolenprogramme weniger als 1000 zeilen gross.
nur die ganzen GUI programme in delphi/pascal sind manchmal bis zu 3500 zeilen lang. aber dazu muss ich sagen, dass die durch die borland-eigene GUI logik und durch die sehr verbose und unausdrucksstarke sprache so aufgeblaeht sind.

ich moechte es noch einmal ausdruecklich erwaehnen:
produktivitaet an codezeilen zu messen, verfuehrt zu code bloat und "quantitaet statt qualitaet".
klassen fuehren auch zu code bloat, wenn man alles in klassen packen will, ohne eigentlich auf das zu gucken, was man "wirklich geschafft" hat.

manche programme werden einfach gross aber auf codezeilen zu achten, macht bestenfalls bei assemblerprogrammierung sinn.

[Gregor@Home]

c.rackwitz schrieb:

ich moechte es noch einmal ausdruecklich erwaehnen:
produktivitaet an codezeilen zu messen, verfuehrt zu code bloat und "quantitaet statt qualitaet".
klassen fuehren auch zu code bloat, wenn man alles in klassen packen will, ohne eigentlich auf das zu gucken, was man "wirklich geschafft" hat.

manche programme werden einfach gross aber auf codezeilen zu achten, macht bestenfalls bei assemblerprogrammierung sinn.

Die Frage ist da doch eher, wie komplex das Projekt sein darf, so dass man es immer noch beherrscht. Wenn einer ein Programm mit 100.000 Zeilen Code beherrscht und weiter sinnvoll warten und erweitern kann, dann sagt das auch einiges über die Qualität des Codes und die Erfahrung des Programmierers aus. Das kann man nämlich nicht, wenn man bezüglich des Designs des Projekts zu viele Fehler macht. Und wenn man darüber reden möchte, dann muss man das auch irgendwie quantifizieren. Und da liegt es IMHO nahe, Zeilen oder etwas ähnliches anzugeben. Wenn du eine Idee für eine bessere Metrik hast, dann bin ich dafür aber auch offen.

Das ist hier also IMHO keine Frage der Produktivität, sondern eine Frage der Beherrschbarkeit: Mit einem guten Design und gutem Code kannst du mehr "Zeilen" beherrschen als mit einem schlechten Design und schlechtem Code. Die Frage ist, wie man komplexere Projekte beherrschen kann und die einfachste und wahrscheinlich auch richtigste Antwort darauf ist: Durch Erfahrung. Da muss jeder seine eigenen Erfahrungen machen (die natürlich nicht völlig separiert von Ideen anderer liegen sollte). Es gibt da kein "Tutorial zur Beherrschung großer Projekte" oder so.

[c.rackwitz]

qualitaet oder produktivitaet am eigentlichen code zu messen, find ich sinnlos.
codezeilen sind da das schlechteste.
eine datei an ihrer bytegroesse messen kommt schon eher hin, weil manche alles in eine zeile packen und andere einen einzigen call ueber 10 zeilen ziehen. dann schreiben aber manche laengere bezeichner und manche nehmen nur einzelne buchstaben.
vielleicht sollte man die knoten in einem optimierten parserbaum zaehlen. dann machen aber manche tausend klassen und sehen nur deswegen noch durch, weil die logik im programm klein ist und nur die umsetzung so wortreich ist.
an der groesse des am ende compilierten optimierten codes zu messen, ist vielleicht auch noch sinnvoll. damit meine ich nicht, dass man verwendete libraries oder resourcen mitzaehlen muss, sondern nur das, was man auch selber verzapft hat.
nicht zu vergessen, ein anfaenger schreibt sich gerne irgendwas komplett neu, auch wenns das schon in verwendbarer form gibt. damit gewinnt man erfahrung aber das programm wird noch komplexer (mehr wartungsarbeit und suche beim debuggen).

alles subjektiv. code kann man nicht objektiv messen und so bald man messen will, kanns passieren, dass die programmierer sich dem kriterium anpassen und die werte verfaelschen.

Mit einem guten Design und gutem Code kannst du mehr "Zeilen" beherrschen als mit einem schlechten Design und schlechtem Code.

wenn das design so gut ist, dann muessen es auch nicht mehr so viele zeilen sein.
ein beherrschbarer code kann von der logik her dichter sein, also hat er auch weniger zeilen. und weil er beherrschbar ist, kann auch mehr logik=mehr zeilen rein.
ein schlechter code beschreibt die gleiche logik mit mehr zeilen. da mehr zeilen auch mehr lesebarbeit bedeutet, wird er damit schlechter wartbar.

meine ueberlegung ist, dass ein code ab einer gewissen zeilenzahl (oder woran man auch immer die verstaendlichkeit misst) einfach immer unwartbarer wird. dann gehts nur noch um gutes design -> mehr logik im gleichen codevolumen.

[Gregor@Home]

c.rackwitz schrieb:

meine ueberlegung ist, dass ein code ab einer gewissen zeilenzahl (oder woran man auch immer die verstaendlichkeit misst) einfach immer unwartbarer wird. dann gehts nur noch um gutes design -> mehr logik im gleichen codevolumen.

Ich stimme mit dir überein, dass gutes Design bei einem größer werdenden Projekt immer wichtiger wird. Allerdings muss gutes Design nicht immer mit "weniger Code für die gleiche Funktionalität" übereinstimmen. Code, der zu kompakt ist, ist auch schlecht wartbar.

[c.rackwitz]

vorausgesetzt "kompakt", "nicht kompakt" und "schlechtes design/amateurhafter code" sind nicht das gleiche

[MBCS-CITP]

c.rackwitz schrieb:

qualitaet oder produktivitaet am eigentlichen code zu messen, find ich sinnlos.
codezeilen sind da das schlechteste.

Es geht auch deshalb nicht, weil die Arbeit, die hinter dem Code steckt hoechst unterschiedlich ist. Ein nerviger Parser fuer merkwuerdiges Text-Daten-Format kann schnell ein paar hundert Zeilen haben (besonders wiederlich das CIFF-Format). Wenn man das Konzept einmal hat, sind diese schnell herunterschrieben. Im Gegenzug hatte ich einmal ein wiederliches Problem Kraefte in Seile zu berechnen. Das Ergebnis waren schliesslich 30 Zeilen Code, diese haben mich jedoch fuenf Arbeitstage gekostet - nicht so sehr das Coding, da war schnell erledigt, sondern mir einen Algorhythmus zu erarbeiten, der das ueberhaupt konnte.

[BF_31]

SideWinder schrieb:

@BF_31: Veröffentliche das doch bei Gelegenheit mal, ich hab auch mal ein privates Forum begonnen und kann Anregungen gebrauchen.

MfG SideWinder

Ich werde vielleicht in 1 Woche hier mal die Adresse bekannt geben. Jetzt ist es noch zu früh, wegen Sicherheitsmängeln. Nicht das so ein Troll kommt und durch Falschangaben mir das ganze Board zerschießt.
Kannst dich aber per eMail an mich wenden, dann gebe ich dir die Adresse mal.

[sarfuan]

sarfuan schrieb:

Nach jedem
Ist doch ganz klar, man nimmt sich etwas vor, malt es sich in Gedanken schon aus und ... übertrifft sich selbst. Ist doch wunderbar
(Man muss nur beim Träumen realistisch bleiben, sich und seine Grenzen kennen ;))

Wa! Holt doch nicht so alte Threads aus der Versenkung. Vor allem nicht, wenn ich nicht merk, dass sie so alt sind, etwas von mir lese und dann kurz erschrecke "wie, was sarfuan? aber das bin doch ich?!" ...

[BloodLord]

Hm... Hello world - extended edition

include <iostream>
using namespace std;

int main(int argc, char *argv[]) {
    char* name;
    if(argv[1]) name=argv[1];
    else name="world";

    cout << "Hello " << name << "!" << endl; } // Hardcore!

Nene, nehmt mich bitte nicht erst

[gack]

include <iostream>
using namespace std;

int main(int argc, char *argv[]) {
    char* name;
    if(argv[1]) name=argv[1];
    else name="world";

    cout << "Hello " << name << "!" << endl; } // Hardcore!

Einbisschen umständlich ....
Also was ich bei euch "viel" sreibern nicht verstehe ist wie ihr den überblick behaltet....
siedwinder: ich hab auf das snake spiel nicht wahnsinnig lust drauf, immerhin werde ich es doch sowieso nicht verwenden, ausserdem sieht das in der Konsole nicht so toll aus ( dan mach ich das lieber mit directX). PS: Ich würde lieber in den software bereich gehen. Hat jemand sonst vorschläge (was ich auch gebrauchen kann - 300 -500 zeilen) ???