Aufbau einer Include - Wie macht man es am besten ?

[STARGÅTE]

Tachchen,

mit der Zeit haben sich bei mir enorm viele Includes (.pbi) angesammelt, die erweiterungen zu PB darstellen.
Alle haben irgendwie den selben inhaltlichen Aufbau, der sich hier und da jedoch auch unterscheidet.

Daher die "Anfängerfrage", wie baut man/ihr eine Include Datei auf.

Meine derzeitige Aufbaustruktur sieht so aus:

• Kommentarkopf (Autor, Quelle, Datum, ...)
• Vorausgesetzte Includes
• Konstanten
• Strukturen
• Var, List, Map, Array Definitionen
• Prozeduren und Makros

Nur so richtig gefällt mir das nicht, weil damit Sachen die Zusammen gehören irgendwie auseinander gerissen werden.
Andere Idee wäre, alles was zu einer procedure gehört auch in ihrem Umfeld zu schreiben (Konstanten, Definitionen, Strukturen)

Wäre gut, wenn ich ein paar Ideen von euch bekomme.

[Falko]

Was ich auch häufig falsch mache,
Proceduren alphanumerisch sortieren, wäre sehr praktisch.
Somit findet man sich rechts in der Liste besser zurecht, wenn's viele
Proceduren sind.

Ebenso ist eine Kommentierung für Abschnitte eine weitere Hilfe die rechts im Editor
aufgelistet werden, was z.B mit Folgendem dargestellt wird:

;--- Kommentartext

Mehr wüsste ich im Moment nicht, was man dazu noch schreiben könnte.

Gruß Falko

[gnasen]

Ich finde das zusammenpacken von Konstanten, Strukturen etc wesentlich übersichtlicher. Das zusammenpacken von Dingen, die miteinander arbeiten halte ich für schwierig, da schnell eine eindeutige Zuordnung schwierig wird, wenn sich zB Prozeduren gegenseitig "überlappen".

Was ich mir sehnlichst wünsche ist ein feature wie namespaces. Eine ganz einfache implementierung würde mir schon reichen.
Das würde das ansammeln von Includes stark vereinfachen, weil zB Strukturen wie Point, Vektor oder ähnliche sehr sehr oft deklariert werden. Ich könnte mir das so vorstellen:

Code: Alles auswählen

namespace vector

  Structure myvec
    x.f
    y.f
  EndStructure

endnamespace


Global someVector.myvec{vector} ;wobei vector nur angegeben werden muss, falls mehrdeutig, sonst compilerwarnung

;oder

UseNameSpace{vector}
  Global someVector.myvec
EndUseNameSpace

ich finde c wirklich nicht schön und bin froh, dass ess PB gibt.... aber die Dinger wären echt praktisch

[NicTheQuick]

Wenn ihr euch sowas wünscht, solltet ihr eine Sprache nutzen, die OOP kann, oder einen Precompiler nutzen.

[HeX0R]

Was ich auch häufig falsch mache,
Proceduren alphanumerisch sortieren, wäre sehr praktisch.
Somit findet man sich rechts in der Liste besser zurecht, wenn's viele
Proceduren sind.

Die Prozedurenliste kannst du doch sortiert darstellen lassen.

[ts-soft]

Wichtig sind eine Beschreibung aller Funktionen mit Parametern und Rückgabewerten.
Desweiteren getestete PB-Version, OS, Unicode, Ascii, x86, x64 und Abhängikeiten.

Der Code sollte auch mit EnableExplicit laufen (also alle Variablen definiert), möglichst keine
Globalen Variablen, bzw. wenn, dann mit einheitlichem Prefix, der dokumentiert ist.

Die im ersten Beitrag von STARGÅTE aufgezählte Reihenfolge halte ich für sehr sinnvoll, aber
letztendlich benutzt man die Include und der Code darin ist nebenrangig.

Allgemeine Strukturen/Konstanen usw., die in PB noch fehlen, sollten mit Compilerdirektiven ver-
sehen werden: CompilerIf Defined(...

Global gültige Dinge wie Strukturen, Konstanten, Interfaces, Prototypes usw. haben in einer Prozedure nichts
verloren.

Alphabetische Reihenfolge ist natürlich quatsch, logische Reihenfolge, so das möglichst kein
declare erforderlich ist wäre sinnvoller.

Mehr gibt es da IMHO nicht zu beachten.

Gruß
Thomas

[Thorium]

Immer prefixes nutzen, auch für Prozeduren. Um Konflikte mit anderen Includes zu vermeiden.

[PMV]

Normalerweise habe ich Deklarationen und der eigentliche Code getrennt
in verschiedenen Dateien. Code, der logisch zu einer bestimmten
Funktionalitätsgruppe gehört, steht dabei noch mals in einer eigenen Datei.
Wenn es sich um wenig Code handelt, sind die Prozeduren am Ende

Code: Alles auswählen

;Kommentarkopf (zugehörendes Projekt, Bezeichnung der Include, Version, Copyright, Beschreibung  der Funktionalität, History)
;Konstanten
;Strukturen und unter jeder Struktur die daraus resultierende globale Liste, Map, Array Definitionen
;Makros
;Declare-Deklarationen
;Proceduren

Da ich persönlich nicht gerne "Declare" verwende, sind meine Prozeduren
nach deren Benutzung sortiert. Nur wenn es nicht anders geht (Zirkelbezug)
wird ein Declare noch mal in die (Haupt)Datei hinzugefügt.

Bei größeren Projekten/ Includes sind die Prozeduren, wie schon gesagt,
in einer extra Datei. Bei solchen größeren Projekten gibt es eine Hauptdatei,
die sämtliche Includes einbindet und den allgemeinen Code enthält, der
keinem bestimmten Bereich zugehordnet werden kann. Auch für diese
Hauptdatei gibt es eine Deklarations-Include, in der Hauptdatei stehen
demnach keine definitionen von Strukturen, Konstanten oder globalen
Variablen. Die Hauptdatei ist demnach normal recht kurz gehalten.

MFG PMV

[GPI]

Edit: Text war blödsinn.

Was auf jeden Fall sinnvoll ist: einen Header wo drin steht, was die Datei macht und was man gegebenfalls beachten muss (abhängigkeiten etc.). Eventuell Versionsnummer mit Datum.

Ansonsten ist der Aufbau relativ.

Es macht Sinn erstmal Struckturen aufzulisten und dann die globalen Variablen. wichtig bei globalen Variablen ist, das diese auf keinen Fall in Konflikt mit anderen treten dürfen. Kannst ja bspw. den PBI-Dateinamen vorne dranhängen. (wenn die datei bspw. Editor.PBI heißt und du eine globale Variabele HauMichTot hast, nenn sie doch _editor_HauMichTot).

Ich würde auch fleißig von den Falten gebrauch machen. ;{ und ;} - damit kannst du Teile wegklappen.

Bei Prozeduren aussagekräftige Namen und Variablennamen nehmen. Am besten gefolgt von einen Kommentar mit einer Kurzbeschreibung. z.b.

Procedure AddHiscore(Names.s,Punkte.l) ; Gibt die Positionsnummer des neuen Hiscores zurück oder 0, wenn kein Hiscore erlangt wurde.

schlecht wäre

Procedure AHS(a.s,b.l)

Kommentare sind das a und o

[Thorium]

Ich nehm gerne eine UNterteilung nach Aufgaben vor.

Ich glaube Stargate meint eher wie man Includes aufbauen sollte, welche man anderen PB-Usern zur Verfügung stellen möchte.