So sehe ich das auch.
Das folgende ist als Tipp und nicht böse gemeint:
Was du geschrieben hast, nennt man landläufig "Crappy Code" bzw. "Quick'n'Dirty". - Es sind sämtliche typischen Anfägerfehler drin bzw. es ist ein Code von kurzer Lebensdauer mit dem Ziel "Ach, ich bastel mal was zusammen und probiere es einfach mal aus". Dieses Lebensende ist nun erreicht.
Es gibt sowas, wie Code-Qualität. Je niedriger die ist, desto instabiler und kurzlebiger wird dein Programm.
Im blödesten Fall läuft es auf einem einzigen PC (deinem), einer einzigen Windowsversion oder lässt sich eben nur mit einer einzigen Compilerversion compilieren.
Unter professionellen Entwicklern gibt es aus diesem Grund gewisse Standards, zu denen die grundlegendsten gehören:
- Alle Variablen deklarieren und denen sinnvolle Namen geben (z.B. die ganzen Einzelvariablen in eine Struktur packen)
- Richtig einrücken (Nicht mal 4 Whitespaces, dann 2 Whitespaces, dann auch mal gar nicht...)
- CamelCase-Schreibweisen festlegen und auch konsequent einhalten
- Leerzeichen und Absätze für die Lesbarkeit - Besonders bei Rechenoperationen
- Abschnittsweise Kommentare setzen, die beschreiben, was überhaupt gemacht wird
- Große Projekte sinnvoll in mehrere Source-Dateien aufteilen
- Datentypen korrekt verwenden und Dokumentationen korrekt verwenden (z.B., wie sieht ein RIFF-WAVE-Header aus und welchen PB-Datentyp muss ich für ein Unsigned-Byte aus der C++-Welt verwenden?)
- Alle Eingaben, die von außen kommen (Usereingaben, Festplatte, Internet...), stets auf Korrektheit überprüfen. Man könnte dir da auch mal was böses reinschummeln!
- Alle Fehler berücksichtigen
- In jede Datei ganz oben reinschreiben, zu welchen Projekt sie gehört, wann sie von wem erstellt wurde und mit was sie zu kompilieren ist (also welche PB-Version)
- Code strukturieren (etwas schwierig in einer nicht-objektorientierten Programmiersprache, aber machbar. Also z.B. in Procedure()-Blöcke portionieren)
- Nicht unnötig umwandeln (z.B. nicht erst vier einzelne Ascii-Bytes auszulesen, um daraus nachträglich mit Chr() einen String zu basteln)
- Fremde Codehäppchen aus dem Internet verstehen ggf. nachbessern und erst dann verwenden. Keine Glue-Codes schreiben.
- Externe Bibliotheken von anderen Entwicklern immer über Wrapper-Prozeduren ansprechen. Dann kannst du die Bibliothek mit geringem Aufwand ersetzen (brauchst dann nur die Wrapper-Prozeduren ersetzen), wenn sie nicht weiterentwickelt, stark verändert oder die Funktionalität von einer späteren PB-Version unterstützt wird. Gilt auch für externe API's - Insbesondere solche, die sich oft verändern (z.B. Google API's
)
Wenn du solche Regeln einhältst, hält der Code über viele PB-Versionen hinweg und fliegt dir nicht bei jeder PB-Version um die Ohren. Evtl. musst du mal ein paar Zeilen anpassen, weil sich die mitgelieferten Bibliotheken oder die Syntax sich verändert haben. Aber das ist dann zum größten Teil eine stumpfe Find/Replace-Aktion.
Dann sind auch x86 vs. x64, Unicode vs. Ascii oder was in der Zukunft noch so kommt, kein Problem mehr.
Außerdem ist es dann auch nicht mehr so fummelig, das Programm auch nach Jahren noch zu erweitern. Möchtest du später z.B. doch noch eine MP3-Unterstützung einbauen, musst du nicht den gesamten Source überarbeiten.
