Grundsätzliche Frage zur Programmstruktur

[Fluid Byte]

Wenn du "Declare FunktionXYZ()" entfernst und versuchst die Prozedur vor dem eigentlichen Procedurcode aufzurufen wird diese nicht erkannt und es gibt einen Compiler-Error. Das macht Sinn wenn man seine Prozeduren (so wie ich) ans Ende seines Codes packt aber sie vorher im Main Loop schon benutzen will.

[Kaeru Gaman]

oder wenn man rückbezügliche Abhängigkeiten hat...

ein Declare-Table kann zusätzlich als Übersicht dienen, wenn man viele Proceduren hat.
ausgiebig kommentierte Declares hat man schneller überblickt,
als ewig zu scrollen und die kommentare in den Procedure-Köpfen nachzulesen.


eins ist mir noch aufgefallen:

Code: Alles auswählen

1. Programm Kommentarkopf
  1.1. Programm-Name
  1.2. Autor
  1.3. Datum
  [1.4.] Kommentar
2. Includes
3. Macros
4. Konstanten
5. Strukturen
6. Globale Variablen
7. Prozedur-Definitionen
8. Eigentliche Prozeduren
9. Hauptcodde (Main)
  9.1. Initalisierungen
  9.2. Der Code
  [9.3.] End
10. DataSection(s) 

ja nach Verfahrensweise kanne s sinnvoller sein,
Macros, Konstanten, Structs und Globals vor den Includes zu haben.
bzw. auch bei den Includes zu trennen, welche Macros und Structs und welche Procs enthalten.

[ts-soft]

Includes sollten IMHO immer Unabhängig vom anderen Sourcen sein, so das
die Reihenfolge, Includes vor Global schon richtig ist.
Rein Projektabhängige Includes (deren Sinn muß jeder für sich entscheiden)
kann man natürlich hinter den Globaldeklarationen einfügen.

[Kaeru Gaman]

da hst du nen wichtigen unterschied angesprochen.

allgemeine Includes, also praktisch "ergänzungen zum Befehlssatz",
bei denen ist es im grunde sogar egal ob sie vor oder hinter den Globals stehen,
zumindest sollten sie so aufgebaut sein, dass es keinen Unterschied macht.
die gehören direkt hinter den Kommentarkopf,
es gibt andere Sprachen / Entwicklungsumgebungen,
wo die Includier-Anweisungen überhaupt nicht mehr im Quelltext stehen,
sondern diese "Befehlsdefinitionen" im Projektmanagement hinzugefügt werden.


bei Projektabhängigen Includes werden unter Umständen identische Structs/Globals benötigt,
wobei es im grunde professioneller wäre, jede Definition in jedem Codeteil stehen zu haben,
und sie mit bedingter Compilierung zu versehen (ob sie schon definiert sind oder nicht)

grundsätzlich kann das aufsplitten einer großen Source in mehrere Includes schon praktisch sein,
auch im sinne der Übersichtlichkeit.
also da ergeben auch projektabhängige Includes einen Sinn.

[ZeHa]

Bei mir hat jeder Programmabschnitt seine eigene Datei (renderer.pb, level.pb, player.pb, menu.pb usw), und diese werden alle innerhalb der main.pb eingebunden. Für globales Zeugs (globale Variablen, Listen, aber auch Strukturdefinitionen und Konstanten usw.) nutze ich meist eine global.pb oder eine common.pb

Daher sieht mein Aufbau der main.pb meist so aus:

Code: Alles auswählen

1. Kommentar mit geilen Sternchen drumrum
2. Includen meiner Wuro Game Lib (okay, erst seit kurzem ;)
3. Includen aller anderen Dateien, common.pb als erstes
4. Ganz wenig Code, meist nur 3 - 20 Zeilen
   (ruft ein paar Initialisierungen auf und startet dann das Programm)

Wenn ich kein Spiel programmiere sondern eine Fensteranwendung, dann habe ich meist auch eine common.pb, manchmal zusätzlich noch eine backend.pb (oder bei komplexeren Dingen auch wieder viele einzelne Dateien für jedes Programm-Modul) und für jedes Fenster i.d.R. ebenfalls eine eigene Datei. Und natürlich wieder eine main.pb, die ähnlich aufgebaut ist wie oben.

[ts-soft]

Bis jetzt wurde eine Begründung gegen "While-Wend" angegeben, dass es evtl. Ereignisse verschluckt. Aber dafür, dass man den Eventloop in eine Procedure packt, bis auf die Übersichtlichkeit (subjektiv) nichts.

Ich packe alle Routinen, die ich mehrfach aufrufe in eine Procedure
Du kannst ja das EventLoop 2x schreiben, das wäre aber sehr altmodisch
und umständlich.

Haste Dir den Code von Edel angesehen? Haste Ihn verstanden?

Sieht nicht so aus

[Kaeru Gaman]

tja... man BRAUCHT aber nen Eventloop doch nicht zweimal, oder?

eben das ist der PUNKT!

wenn ihr der Meinung seit, DEN Eventloop mehr als einmal benutzen zu wollen, können, müssen
dann beschreibt doch bitte die Situation wann, wie, warum,
und stellt euch nicht nur einfach hin und lamentiert "wer das nicht sieht ist doof"

[ts-soft]

Das haben wir doch die ganze Zeit gemacht!

Um z.B. die Events bei Erstellung und Füllung der Gadgets abzuarbeiten,
wenn diese dann sichtbar sind.

Oder wenn man längere Routinen abarbeitet, damit das Fenster nicht
verblaßt, und man nicht für jeden Scheiß gleich nen Thread benötigt usw.

Wers jetzt noch nicht verstanden hat, tut mir einfach nur leid, ich bin hier
kein Lehrer, fehlt mir die Zeit.

[ZeHa]

Oder wenn man längere Routinen abarbeitet, damit das Fenster nicht
verblaßt, und man nicht für jeden Scheiß gleich nen Thread benötigt usw.

Sorry, aber ein solches rumgehacke kann keiner als "Die beste Lösung überhaupt!!!1" verkaufen.
Wer eine länger ablaufende Routine hat, der soll diese in einen Thread packen, und nicht nach jedem zweiten Statement mal eben kurz den EventLoop aufrufen. Ich glaube "Die beste Lösung überhaupt!!!1" trifft dafür eher zu als für jeden Hack.

[Kaeru Gaman]

> Um z.B. die Events bei Erstellung und Füllung der Gadgets abzuarbeiten,
> wenn diese dann sichtbar sind.

da entgeht mir der sinn, denn die bauen ja langsam auf,
wenn ich nach der erstellung direkt in den Mainloop gehe,
deswegen baut man ja versteckt auf und läßt die events fressen bevor man anzeigt.

oder rufst du deine eventloop-proc nach jedem einzelnen gadget-command auf?

> Oder wenn man längere Routinen abarbeitet, damit das Fenster nicht
> verblaßt, und man nicht für jeden Scheiß gleich nen Thread benötigt usw.

also du rufst nen kompletten eventloop bei jedem durchgang einer berechnungsschleife auf?
dann kannst du aber nix mehr mit WaitWindowEvent anfangen.
da fände ich es aber wesentlich effektiver die berechnung sauber
in den Eventloop zu integrieren bzw. mit nem thread zu arbeiten.


> Wers jetzt noch nicht verstanden hat, tut mir einfach nur leid, ich bin hier
> kein Lehrer, fehlt mir die Zeit.

tja was soll man da noch sagen

...dann ist es eben doch nur heiße luft.