Modellbahnsteuerung in Delphi

[Codehunter]

Moin! Ich habe eben zufällig diesen netten Artikel bei Heise entdeckt. Lohnt sich zu lesen.

[Sherlock]

Sehr schön!
Das Codebeispiel allerdings...smells
Und das kenne ich nur zu gut.

Sherlock

[Der schöne Günther]

Mit dem Codebeispiel lockt man sicher eine Menge Leute, sich Delphi näher anzuschauen.

Ich glaube ich habe ein neues Negativbeispiel für "Bringen sie ein paar beliebige Quellcodefragmente zum Bewerbungsgespräch mit"

[Union]

Sehr interessanter Artikel. Vor einiger Zeit habe ich auch mal irgendwo eine Doku darüber gesehen. Das Sourcebeispiel ist ... interessant. Besonders da dort schon ARC eingesetzt wird, dadurch spart man sich das Exceptionhandling Laut Wiki muß der Source ca. 10-12 Jahre alt sein, sieht aber aus wie 40.

[Insider2004]

Das Codebeispiel ist ja der reinste Horror. Das erinnert an Basic in Chip 1988. Aber der Erfolg gibt ihm Recht. Solange nur der Entwickler Hand anlegt ist alles gut!

[bernau]

"Dann mal Butter bei die Fische". Was ist schlecht. Ich sehe auch ein paar Punkte, aber Ihr habt kritisiert.

Vorab: Codeformatierung bitte aussen vor lassen, da in dem Artikel der Code einfach so reingepresst wurde. Der Code wird im Original wahrscheinlich besser formatiert sein.

[Codehunter]

Was ich eigentlich viel interessanter finde als das Codesample ist die Tatsache, dass da anscheinend 100 Rechner arbeiten. Jeder hat mit Sicherheit irgendwelche Spezialaufgaben und das Ganze wird dann von einem Delphi-Projekt koordiniert. Früher nannte man sowas mal Multi-Tier-Anwendung. Da bei dem Anwendungsfall im wahrsten Sinne viele kleine Rädchen nahezu in Echtzeit koordiniert werden müssen, finde ich das Ganze schon beachtlich.

Solange da nur ein Entwickler am Werk ist mag das Projektmanagement auch so OK sein. Aber was ist wenn der eine Entwickler mal ausfällt? Ist doch ein Paradebeispiel für SPoF. Ganz ehrlich, würde ich dort arbeiten in dem Wissen es hinge alles an einem einzigen Kollegen, ich hätte gewaltig Bauchschmerzen.

[Lemmy]

Hi,
fühl mich nicht angesprochen, weil ich die Sourcen nicht "horror" finde. Sind vielleicht anstregende...

was mich stört:
* Variablennamen (j, x, y,....)
* zu lange Prozedur

Allerdings ließe sich zumindest der zweite Punkt recht gut lösen, da aufgrund der KOmmentare schon Blöcke "vordefiniert" sind, d.h. das ließe sich einfach neu strukturieren (refaktoring), was auch die Problematik der Variablennamen recht schnell lösen würde.

Weiter deutet der Prozedurname darauf hin, dass es das auch für Autos, Busse,.. in ähnlicher Form geben wird, d.h. dass hier evtl. Potential zum Code-Einsparen da ist, wenn man das Projekt etwas anders strukturiert.

Allerdings muss ich schon sagen, dass ich schon deutlich schlechteren Code gesehen habe:
Prozedurkopf: Zeile 961
Prozedurbeginn: Zeile 2108 (dazwischen auf 1.200 Zeilen Inline-Prozeduren und -Funktionen)
ProzedurEnde: Zeile 2920

Der Var-Block der Prozedur liegt natürlich VOR den Inline-Prozeduren, so dass man das auch nicht so einfach auflösen kann

[Morphie]

• Variablennamen gehören bei mir in englischer Sprache deklariert. Aber das ist offenbar Geschmackssache. Grundsätzlich sollte man sich aber festlegen VerschiebX, VerschiebY: integer; / help: string;
• Gibt man den Variablen jetzt sprechende Namen oder nicht? Breite, hoehe: integer; / b2: tbitmap;
• Ständig wird auf ein Array über einen (für mich) zu langen Variablennamen zugegriffen... Übersichtlicher fände ich das einmalige zwischenspeichern in eine zusätzliche Variable. SchiffeTMP[EinOderAuszublendeneNummer]
• Woher kommt denn EinOderAuszublendeneNummer? Ist das ein Feld, oder ein Property der Klasse? Oder eine globale Variable? Hätte man es vielleicht besser als Parameter der Methode deklarieren können? Es ist für mich nicht sofort ersichtlich.
• Kein Try-Finally-Schutzblock... Was, wenn es irgendwo zwischen b2:=tbitmap.create; und b2.free; knallt?

Nur so überflogen... Das ist allerdings meine subjektive Meinung. Da der Programmierer wohl allein an seiner Software arbeitet, kann der Code für ihn selbst möglicherweise übersichtlich genug sein.

[Union]

Zitat von bernau:

"Dann mal Butter bei die Fische". Was ist schlecht. Ich sehe auch ein paar Punkte, aber Ihr habt kritisiert.

Vorab: Codeformatierung bitte aussen vor lassen, da in dem Artikel der Code einfach so reingepresst wurde. Der Code wird im Original wahrscheinlich besser formatiert sein.

• Der Code ist nicht gegen Abstürze gesichert, es wid ein Objekt erzeugt (b2=TBitmap) und auch wieder freigegeben, aber es fehlt ein try Konstrukt.
• Das Array SchiffeTMP ist wohl global. Die gezeigte Prozedur weits vom Namen her daruf hin, dass sie in einem Thread aufgerufen wird. Es wird aber ohne entspechendes Locking auf das Array zugegriffen.
• Das Gleiche gilt für den Zugriff auf die "Zeichenfläche" QuellbildmitSchiffen
• Die Abfrage auf die Lage (Drehung in Grad) sollte besser mit case erfolgen. Zudem fehlt der else Zweig bei dem zweiten Abfrageblock - was geschieht bei ungültigen Daten, z.b. negative Gradzahlen oder > 360?