"Programmier-Knigge" für Prozedurales Programmiere
Verfasst: 08.05.2006 10:59
Hallo zusammen,
ich habe eine (vermutlich wieder sehr eigene) Frage zum Programmieren mit PureBasic 4. Ich bin Purebasic Anfänger, jedoch ansonsten programmiererfahren (mit leichtem Rostansatz
) und würde demnächst meine ersten Schritte in PB4 machen wollen.
Purebasic ist ja eine prozedurale Sprache und keine objektorientierte, wenn ich das bisher richtig relaisiert habe.
Gibt es vom PB-Entwicklerteam eine Art "Leitfaden", wie bestimmte Projekte auf Sourcecodebasis möglichst effektiv zu handhaben sind? Oder wie bestimmte Workflows bei der Arbeit mit PB4 auszusehen haben? Also soetwas wie Design-rules für PB4 Projekte?
Es ist so, daß ich vor laaaaaanger Zeit auf de Amiga in AMOS programmiert habe. Das war auch eine prozedurale Sprache, jedoch ohne multitab-Support im Editor, wenn ich mich recht entsinne. Außerdem habe ich dort eher kleine Programme für den Eigenbedarf entwickelt - also nichts aufwändiges und somit auch nichts, wo man großartig über die Struktur des Sourcecodes nachdenken musste.
Jetzt ist es so, daß ich beruflich bedingt eine ganze Zeit lang nur mit Datenbankprogrammierung zu tun hatte und mit Entwicklungstools arbeite, die sich Semi-Objektotientiert programmieren lassen. Seit '96 bin ich kein Amigauser mehr und habe seitdem privat auch nix mehr mit programmiert.
Lange Rede, kurzer Sinn. Ich würde gern wieder einmal privat "einsteigen" und dabei fensterbasierte Anwendungen mit Purebasic erstellen. Allerdings bin mir noch nicht sicher, wie und ob ich die einzelnen Aufgaben eines Projektes/Programmes auf verschiedne Tabs und demzufolge includierbare Sourcedateien auslagern sollte. Also z.b. den Code zur Fenster-Eventbearbeitung oder eine include-Datei nur mit Fileoprationen oder mit den nichtvisuellen Funktionen/Proceduren oder eben doch ganz anders)
Bei dem objektorientiertem Entwicklertool, welches ich bisher beruflich nutze, muß man sich um die Eventabfragen der einzelnen Fenster etc. keine Gedanken machen. Man erstellt halt einfach Code für den gewünschten Event und der wird von der IDE auch entsprechend verwaltet und in einer entsprechenden Gruppe dargestellt (Centura).
Die Beispielcodes, die Purebasic beiliegen sind Projekt-technisch allesamt zu kurz oder es wurde nicht darauf geachtet, als daß man sich hier Ideen für die Aufteilung eines Projektes holen könnte.
Daher meine Frage.
Gibt es irgendwie Tipps und Regelvorschläge für die Programmierung unter Purebasic? Also als Beispiel, so etwas, daß man für jedes Formular (Fenster) und deren Eventbehandlung eine eigene Datei erzeugt und diese eben auch als einzelnen Tab im Editor anzeigt. Oder so, daß das Projekt einen kleinen Rumpfcode becommt, in dem die einzelnen Dateien, aus denen das Projekt besteht, includiert werden. Also so ähnlich wie ein Delphi Projekt.
Es ist bei mir schon echt lange her, daß ich prozedural programmiert habe und ich würde gern vorab gucken wie es andere machen, um mich bei großen Projekten nicht zu verheddern ("Spaggethicode") und um eben solche Fehler und einen "ungünstigen Programmierstil" gar nicht erst aufkeimen zu lassen.
Ist alles etwas hampelig beschrieben, aber ich hoffe, ihr wißt in etwa was ich meine.
Mit besten Grüßen
Markus
ich habe eine (vermutlich wieder sehr eigene) Frage zum Programmieren mit PureBasic 4. Ich bin Purebasic Anfänger, jedoch ansonsten programmiererfahren (mit leichtem Rostansatz

Purebasic ist ja eine prozedurale Sprache und keine objektorientierte, wenn ich das bisher richtig relaisiert habe.
Gibt es vom PB-Entwicklerteam eine Art "Leitfaden", wie bestimmte Projekte auf Sourcecodebasis möglichst effektiv zu handhaben sind? Oder wie bestimmte Workflows bei der Arbeit mit PB4 auszusehen haben? Also soetwas wie Design-rules für PB4 Projekte?
Es ist so, daß ich vor laaaaaanger Zeit auf de Amiga in AMOS programmiert habe. Das war auch eine prozedurale Sprache, jedoch ohne multitab-Support im Editor, wenn ich mich recht entsinne. Außerdem habe ich dort eher kleine Programme für den Eigenbedarf entwickelt - also nichts aufwändiges und somit auch nichts, wo man großartig über die Struktur des Sourcecodes nachdenken musste.
Jetzt ist es so, daß ich beruflich bedingt eine ganze Zeit lang nur mit Datenbankprogrammierung zu tun hatte und mit Entwicklungstools arbeite, die sich Semi-Objektotientiert programmieren lassen. Seit '96 bin ich kein Amigauser mehr und habe seitdem privat auch nix mehr mit programmiert.
Lange Rede, kurzer Sinn. Ich würde gern wieder einmal privat "einsteigen" und dabei fensterbasierte Anwendungen mit Purebasic erstellen. Allerdings bin mir noch nicht sicher, wie und ob ich die einzelnen Aufgaben eines Projektes/Programmes auf verschiedne Tabs und demzufolge includierbare Sourcedateien auslagern sollte. Also z.b. den Code zur Fenster-Eventbearbeitung oder eine include-Datei nur mit Fileoprationen oder mit den nichtvisuellen Funktionen/Proceduren oder eben doch ganz anders)
Bei dem objektorientiertem Entwicklertool, welches ich bisher beruflich nutze, muß man sich um die Eventabfragen der einzelnen Fenster etc. keine Gedanken machen. Man erstellt halt einfach Code für den gewünschten Event und der wird von der IDE auch entsprechend verwaltet und in einer entsprechenden Gruppe dargestellt (Centura).
Die Beispielcodes, die Purebasic beiliegen sind Projekt-technisch allesamt zu kurz oder es wurde nicht darauf geachtet, als daß man sich hier Ideen für die Aufteilung eines Projektes holen könnte.
Daher meine Frage.

Gibt es irgendwie Tipps und Regelvorschläge für die Programmierung unter Purebasic? Also als Beispiel, so etwas, daß man für jedes Formular (Fenster) und deren Eventbehandlung eine eigene Datei erzeugt und diese eben auch als einzelnen Tab im Editor anzeigt. Oder so, daß das Projekt einen kleinen Rumpfcode becommt, in dem die einzelnen Dateien, aus denen das Projekt besteht, includiert werden. Also so ähnlich wie ein Delphi Projekt.
Es ist bei mir schon echt lange her, daß ich prozedural programmiert habe und ich würde gern vorab gucken wie es andere machen, um mich bei großen Projekten nicht zu verheddern ("Spaggethicode") und um eben solche Fehler und einen "ungünstigen Programmierstil" gar nicht erst aufkeimen zu lassen.
Ist alles etwas hampelig beschrieben, aber ich hoffe, ihr wißt in etwa was ich meine.
Mit besten Grüßen
Markus