Eigenes Programm prüfen

  • Hallo,


    wie ihr wisst möchte ich programmieren lernen.

    Mich würde mal interessieren wie man sein eigenen Code prüft ohne das Gesamtprojekt zu gefährden. Ich hatte mich mal in Pascal probiert und hatte mal Wörter die ich erraten mußte. War ohne Datei schreiben oder lesen. Es hatte aber funktioniert. Nun da hatte ich PROCEDURE und bin mit GOTO hingesprungen. Dadurch hatte ich Blöcke die ich nutzen konnte oder nicht.


    Um etwas zu prüfen braucht man die Variablen die man in einer IDE einblenden kann. Aber bei einem Programm von 100 Zeilen oder später 1'000 wie behält man da den Überblick seiner Variablen? Und wie prüft man sein eigenen Code? Lagert man das Prüfprogramm aus? Bei C ginge das mit include. Bei Pascal kann man bestimmt eine außen liegende Datei aufrufen. Aber wie muß man denken bei einer Prüfoption?


    Ich würde gern Pascal und C und C++ lernen - in der Reihenfolge :-))


    mfg

  • für das testen einzelner code-teile hab ich zwar keine antwort für dich aber ein tip am rande: hab damals den norton-commander mit ner erweiterung benutzt und hatte da syntax-highlightning. das hilft um tipfehler oder ähnliches sofort zu entdecken. können auch viele andere programme. auf jedenfall war das für mich ne tolle hilfestellung ^^

    viel erfolg beim lernen :)

  • Naja, man kann Unit Tests schreiben. Früher(tm) hat man so etwas eher nicht gemacht. Aber heutzutage ist das eigentlich Standard. Und der Name ist Programm: du hast bei Pascal doch Units mit Interfaces. Schneide dein Programm in sinnvolle Units und schreibe zu diesen kleine Testprogramme, die jeweils genau eine Unit testen. Die Herausforderung ist nun das ganze so zu entwerfen, dass die Units möglichst keinerlei Abhängigkeiten untereinander haben. Dann kannst du getrennt voneinander testen und auch Units durch andere Implementierungen austauschen.

    root42 auf YouTube


    80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, GUSar Lite & TNDY & SnarkBarker, PC MIDI Card + SC55 + MT-32, XT CF Lite, OSSC 1.6

  • Über eine sinnvolle Aufteilung des Programms in Prozeduren, Funktionen und Units erhältst du ja Code-Blöcke, die du gut einzeln testen und einen Fehler so eingrenzen kannst.

    Eine gute Organisation ist bei großen Projekten alles. Unter Pascal gibt es auch die Möglichkeit von Include-Dateien, die ich dafür gerne nutze ( {$I Beispieldatei.inc}. Der Compiler springt dann an der Stelle in die angegebene Datei, macht dort mit dem Compilieren weiter und wenn die abgearbeitet ist, springt er zur ersten Quellcodedatei zurück und macht dort weiter. So kannst du deinen Code in verschiedene kleine und übersichtliche Dateien aufteilen, ohne gleich Units zu erstellen und hast keine unübersichtliche Hauptdatei mit 1000 Zeilen.


    Hier kann man dann ja auch eine Datei erstellen, die nur die Variablen und Konstanten enthält und die du in der Entwicklungsumgebung immer nebenbei geöffent haben kannst (früher hätte man sich die dann wahrscheinlich ausgedruckt neben den Monitor gelegt :) ). So hast du deine bisher definierten Variablen beim Schreiben des weiteren Codes immer Blick und es wird nicht unübersichtlich. Natürlich ist es dann empfehlenswert, möglichst mit globalen Variablen für das ganze Programm zu arbeiten und nicht in jeder Prozedur eigene Variablen anzulegen. Auch die Benennung der Variablen usw. ist natürlich wichtig, um in großen Projekten den Überblick zu behalten. Hier lohnt sich die Mühe, quasi objektorientiert zu arbeiten, zumindet bei den Namen. Also z.B. eine Variable als "Fileselector.Dateiname : string[12]" anstatt nur "Name : string[12]" oder gar "N : string[12]" zu definieren. Mehr Schreibaufwand, aber auch kaum Gefahr sich bei großen Projekten später zu verzetteln.


    Ich nehme auch gerne Pascal zum Programmieren unter DOS und das jetzt schon seit 25 Jahren. :D Später habe ich mir selbst Visual C++ beigebracht, um auch unter Windows programmieren zu können (immer nur als Hobby).

    Zum lernen kannst du dir gerne mal die Projekte auf meiner Github-Seite ansehen. Da ist viel Pascal dabei.

    Meine DOS-Rechner:

    Kleiner Industrie-486er mit 100 MHz (Intel 80486DX-4), 32 MB SD-RAM, Diamond SpeedSTAR 24 und SB 16 ( CT2770 ) + TNDY

    "Frankenstein" Pentium II mit 266 MHz, Elsa Winner 1000 TrioV + Voodoo I, SB 16 (CT2290) + Yamaha DB50XG


    Von mir geschriebene DOS-Programme gibt es hier.

  • für das testen einzelner code-teile hab ich zwar keine antwort für dich aber ein tip am rande: hab damals den norton-commander mit ner erweiterung benutzt und hatte da syntax-highlightning. das hilft um tipfehler oder ähnliches sofort zu entdecken. können auch viele andere programme. auf jedenfall war das für mich ne tolle hilfestellung ^^

    viel erfolg beim lernen :)

    Die Idee ist gut. Aber leider weiß ich nicht ob es mit einer Datei gut ist zu lernen. Ich dachte eine IDE ist da besser für den Anfang? Weil mehr Möglichkeiten. Wenn ich die Datei compiliere was sagt mir der Compiler dann alles? Mit einer IDE sehe ich die Zeile und kann gleich hinspringen.


    Was muß ich wissen das mich das überzeugen könnte es mit nem Editor und nem Compiler auf der Befehlszeile zu versuchen?


    Es gibt viele Editoren die Befehle einfärben. Ich habe aber Angst nur den Compiler auifzurufen das würde mich dann überfordern, weil ich vielleicht auf Komfort verzichten müßte. Ich weiß es halt nicht, daß könnte mir nur einer erzählen der programmiert. Was er lieber hat - eine IDE oder ein reinen färbenden Editor?


    mfg

  • Naja, man kann Unit Tests schreiben. Früher(tm) hat man so etwas eher nicht gemacht. Aber heutzutage ist das eigentlich Standard. Und der Name ist Programm: du hast bei Pascal doch Units mit Interfaces.

    .. jetzt müßte ich nur noch wissen was Units sind?

  • Eine gute Organisation ist bei großen Projekten alles. Unter Pascal gibt es auch die Möglichkeit von Include-Dateien, die ich dafür gerne nutze ( {$I Beispieldatei.inc}. Der Compiler springt dann an der Stelle in die angegebene Datei, macht dort mit dem

    Hallo,


    das mit Pascal hatte ich fast vergessen ,mit include.


    Bei Pascal hatte ich die Procedure oben stehen und unten dann goto. Das fand ich sehr angenehm, weil ich so Sprünge ausschalten konnte. Aber ich habe oft gelesen man soll nicht so viel springen.


    Ich frage mich halt was zum guten Stil gehört. Die Variablen alle auf einen Fleck definieren oder geht das unten tiefer im Programm vor einem Block? Wie ich denken muß um den Spaß nicht zu verlieren, daß fand ich bisher nirgends geschrieben.

    Genauso das Einrücken von Zeilen. Darüber habe ich einiges gelesen. Aber davon ist bei mir nichts hängen geblieben.


    Und wie schreibt man Kommentarzeilen das sie andere verstehen würden? Wie man denkt im Alltag oder wie der Block funktioniert? Wenn ich wüßte wie ein Programmierer denkt, dann würde ich vermutlich gut lernen. So lese ich 5 mal was über grüne Tomaten und nach dem 3 mal lesen weiß ich sie sind noch nicht reif :-))


    mfg

  • .. jetzt müßte ich nur noch wissen was Units sind?

    Units sind Dateien, die nützliche Programmbausteine enthalten, die in deinen Programmen verwendet werden können. Bei anderen Programmiersprachen heißen die Units Libraries bzw. Bibiotheken, ist aber dasselbe.


    Diese Units können entweder als Quellcode vorliegen, und in denen Programmen mitkompiliert werden, oder sie können bereits kompiliert sein und werden zum Schluss in dein Programm eingebaut (gelinkt).


    Wenn du z.B. schreibst

    Pascal
    Uses Crt;

    Dann baust du die Unit namens "Crt" in dein Programm ein, die zur Ansteuerung des Bildschirms dient (der war damals eben ein CRT). Dadurch kannst du die Funktionen der Unit benutzen und musst nicht ständig das Rad neu erfinden ;) Kompilierte Units haben die Dateiendung .tpu (Turbo Pascal Unit), ansonsten wie üblich .pas.


    Unter C/C++ sieht das so aus:

    C
    #include <stdio.h>

    Damit fügst du die Library "stdio" ein, die zur Ein- und Ausgabe dient (Standard Input/Output). Warum .h? Bei C gibt es etwas weiteres, nämlich die Header-Datei (.h), die einfach nur eine Inhaltsangabe der Library ist und ins Programm direkt eingebunden wird, während er Code der Library sich in einer eigenen Datei befindet (Quellcode: .c, .cpp oder Kompilat: .lib, .dll, .so …)

  • Die IDE von Borland Pascal 7 färbt auch den Syntax doch auch ein :)


    Bestimmte Funktionen und Prozeduren brauchst du ja immer wieder für verschiedene Programme. Hier wäre es ja Mist, die immer wieder in deinen Quellcode kopieren zu müssen. Dafür sind die Units.

    Hier werden Prozeduren und Funktionen zusammengefasst und auch bereits kompiliert (.TPU - Datei), sodass sie vom Compiler später sehr schnell eingebunden werden können.

    Es sind schon jede Menge Units bei deinem Pascal-Compiler dabei, die die Standardbefehle enthalten.


    Beispiel:


    Code
    Program Beispielprogramm;
    uses crt;
    
    begin
     clrscr;
     writeln('Hallo OS/2-Fan');
     while keypressed do readkey;
     repeat until keypressed;
    end.


    CRT ist eine Unit, die schon bei Pascal mitgeliefert wird und in der Borland Standartfunktionen für Bildschirmausgaben und Tastatursteuerung usw. zusammengefasst hat. Dein Programm bindet Units über "uses" ein und dadurch kannst du dann die Proceduren und Funktionen nutzen, die in der Unit stehen.

    Hier zum Beispiel "clrscr" (Clear Screen), readkey und keypressed.


    Wenn du selber eine Unit schreiben willst, geht das fast wie ein normales Programm. Nur der Aufbau ist etwas anders.


    Hier eine Mini-Unit, die eine Prozedur hinzufügt, mit der du in Zukunft immer ganz schnell einen Titel zentriert in die oberste Zeile schreiben kannst.

    In deinem Programm musst du nur die "Testunit" unter "uses" ergänzen uns schon kann "Schreibe_Titel" aufgerufen werden.

    Unter "interface" wird im Quellcode von Units einmal aufgelistet, welche Proceduren und Funktionen von Programmen aus der Unit aufgerufen werden können und unter "implementation" steht dann der Code davon.


    Jetzt klar? :)

    Meine DOS-Rechner:

    Kleiner Industrie-486er mit 100 MHz (Intel 80486DX-4), 32 MB SD-RAM, Diamond SpeedSTAR 24 und SB 16 ( CT2770 ) + TNDY

    "Frankenstein" Pentium II mit 266 MHz, Elsa Winner 1000 TrioV + Voodoo I, SB 16 (CT2290) + Yamaha DB50XG


    Von mir geschriebene DOS-Programme gibt es hier.

  • Jetzt war H.EXE schneller :)


    Zitat

    Ich frage mich halt was zum guten Stil gehört. Die Variablen alle auf einen Fleck definieren oder geht das unten tiefer im Programm vor einem Block? Wie ich denken muß um den Spaß nicht zu verlieren, daß fand ich bisher nirgends geschrieben.

    Genauso das Einrücken von Zeilen. Darüber habe ich einiges gelesen. Aber davon ist bei mir nichts hängen geblieben.


    Und wie schreibt man Kommentarzeilen das sie andere verstehen würden? Wie man denkt im Alltag oder wie der Block funktioniert? Wenn ich wüßte wie ein Programmierer denkt, dann würde ich vermutlich gut lernen. So lese ich 5 mal was über grüne Tomaten und nach dem 3 mal lesen weiß ich sie sind noch nicht reif :-))

    Programmierer bin ich selber auch nicht und habe es auch nie "offiziell" gelernt. Alles selbst beigebracht und kann dir daher nur sagen, was für mich gut funktioniert hat, um mich bei großen Projekten nicht zu verzetteln. :)

    Einrücken ist sicherlich sehr sinnvoll für die Lesbarkeit. Neuere Texteditioren für Programmierer rücken ja automatisch ein etc.

    Meine DOS-Rechner:

    Kleiner Industrie-486er mit 100 MHz (Intel 80486DX-4), 32 MB SD-RAM, Diamond SpeedSTAR 24 und SB 16 ( CT2770 ) + TNDY

    "Frankenstein" Pentium II mit 266 MHz, Elsa Winner 1000 TrioV + Voodoo I, SB 16 (CT2290) + Yamaha DB50XG


    Von mir geschriebene DOS-Programme gibt es hier.

  • das syntax highlightning zeigt nur farbig an, was verständliche befehle sind und welche befehle auf welche programmteile verweisen, mehr nicht. bleibt ein befehl z. b. weiß, dann ist vermutlich ein tipfehler drin oder das programm kennt den befehl schlicht nicht.

  • Dann baust du die Unit namens "Crt" in dein Programm ein, die zur Ansteuerung des Bildschirms dient (der war damals eben ein CRT). Dadurch kannst du die Funktionen

    Ich hatte gelesen das man sich die selbst schreiben kann. Und wie weiß ich dann was drin steht? Interessant ist halt später wenn man im Team schreiben würde. Es gibt ja die Kästchen die man mit Strichen verbindet und stellt so die Funktion eines Programmes dar. Nur nicht solche Kastenbilder auch ein Hobby-Programmierer? Oder nimmt man die um bessere Lösungen zu finden? Oder nimmt man die ab einer bestimmten Code Zeilen?


    Wie behält man den Überblick? Schreibt man den Kommentar einer selbst geschrieben Unit ins Hauptprogramm?


    Mir wollte einer mal was erklären und hat Code geschrieben. Für mich war seine Nachricht wertlos, weil ich sie nicht nachvollziehen konnte.


    mfg

  • Jetzt klar?

    Gut erklärt :- )

    Aber wenn die vorher compiliert werden, dann kann die doch nicht mehr lesen. Woher weiß ich dann nach Wochen was das Ding kann? Und was für Aufgaben schreibt man da rein? 1 oder mehrere. Solche Kleinigkeiten beschäftigen mich, weil ich das Ausmaß des Lernumfangs nicht kenne, nicht mal erahne. Solche Antworten suche ich ewig. In Videos nie zu finden. Ich habe das Gefühl 30 mal um die Erde laufen zu müssen. Ein Programmierer wüßte das es vielleicht nur /2/ mal sind. Deshalb weiß ich auch nicht was ich lernen muß - mir fehlt ne Roadmap :) Wie bei Programmen wo man die Zukunftspläne veröffentlicht. Ich sitze planlos da und nehme alles auf, weil ich nicht weiß was wichtig ist.


    Verstehste was in mir vorgeht? :- )

  • Programmierer bin ich selber auch nicht und habe es auch nie "offiziell" gelernt. Alles selbst beigebracht und kann dir daher nur sagen, was für mich gut funktioniert hat, um mich bei großen Projekten nicht zu verzetteln. :)

    Einrücken ist sicherlich sehr sinnvoll für die Lesbarkeit. Neuere Texteditioren für Programmierer rücken ja automatisch ein etc.

    Für mich ist ein Programmierer schon der was auf die Beine stellt und es läuft :- )


    Mich hätte interessiert wie man einrückt? Gibt es 5 Regeln dazu oder 10?


    Den letzten Absatz habe ich erst im Zitat entdeckt. Automatisch einrücken klingt verlockend :- )) Um sich einen Stil anzueignen.

  • @OS/2-Fan: Du kannst die selbst schreiben … ich finde die Erklärung von Dragonsphere dazu extrem lehrreich ;)


    Was drin steht?

    • Ist es eine .pas-Datei, schau rein. Manchmal ist eine Dokumentation dabei, meistens Kommentare in der Datei. Das erklärt, was die Funktionen als Eingabe erwarten, was sie tun und was sie als Ausgabe zurückliefern.

    • Ist es eine .tpu-Datei, wird sicher eine Dokumentation dabei sein, die dir sagt, wie du sie benutzen kannst.


    Es ist wichtig, auf jeden Fall, egal welche Programmiersprache, den Code zu kommentieren. Das heißt, du schreibst an den Anfang deiner Unit einen Kopf-Kommentar, der erklärt, wozu diese Unit da ist, wer sie geschrieben hat und wann. Dann über jede einzelne Funktion/Prozedur einen weiteren Kommentar, wie man diese Funktion benutzt: Eingabe, Tätigkeit, Ausgabe.


    Die "Kastenbilder" heißen Programmablaufpläne (PAP). Die sind sehr hilfreich, nicht nur für andere, sondern auch für dich: Um das Programm zu planen, doppelte Stellen zu finden und das Programm sinnvoll in Einzelabschnitte zu unterteilen. Ich empfehle dir auch welche zu erstellen, sobald du das gefühl hast, dass das Programm etwas komplexer wird – schaden kann es nicht. Schon bei Wikipedia findest du ein einfaches Beispiel.


    Zum Thema einrücken: Eigentlich gibt es nur eine echte Regel … du rückst dann ein, wenn du die "Ebene" wechselst, also z.B. wenn du von deinem normalen Ablauf in eine If-Anweisung oder Schleife abzweigst. Für jeden weiteren Wechsel der Ebene eine weitere Einrückung, ist die Ebene "vorbei", geht die Einrückung zurück. Die Einrückung selbst ist eigentlich Geschmackssache, ich verwende Tabs. Manchmal entspricht ein Tab 4 Leerzeichen, manchmal 8. Probier es aus, ist sowieso nur Formsache.


    Bei C/C++ würde es dann so aussehen:

    C
    int meine_funktion(int a, int b)
    {
        int x;
        x = a + b;
        if(x < 0)
        {
            x = 0;
        }
        return x;
    }
  • das syntax highlightning zeigt nur farbig an, was verständliche befehle sind und welche befehle auf welche programmteile verweisen, mehr nicht. bleibt ein befehl z. b. weiß, dann ist vermutlich ein tipfehler drin oder das programm kennt den befehl schlicht nicht.

    Also nur wie hier im Forum die Wörter lesen Spellcheck nennt sich das glaube ich.

  • naja dein ganzer quellcode ist halt schön bunt :D und das schon beim schreiben. bestimmten funktionen sind bestimmte farben zugeordnet. erkennt das programm einen befehl, wird der entsprechend farbig dargestellt. und zusammengehörige zeilen wurden imho auch in eigenen farben gekennzeichnet.

    macht es anhand der farbigen darstellung einfach fehler zu sehen. wenn etwas weiß bleibt, hat es für das programm keine erkennbare funktion und wird als text interpretiert. falls es eine funktion haben soll, dann hast du dich wohl vertippt oder einen fehler gemacht und musst dir den teil nochmal ansehen...


    ganz genau weiß ich auch nicht mehr wie das gearbeitet hat, ist schon mehr als 20 jahre her. aber damals hat mir die funktion sehr geholfen simple fehler zu erkennen. wie gesagt, ist nur für schreibweise und beziehungen nützlich, nicht für einen test des programms. ich fands damals für mich nützlich ^^

  • ---------------------

    Gibt es 5 Regeln dazu oder 10?

    --------------------


    Soviel Regeln wie programmierer.


    Wie beim Stricken : eins rechts , eins links, Masche fallen lassen.....oder eins links , eins rechts Masche hoch holen


    Was ist richtig...? Du liegst immer falsch wenn du die programmierer fragst.

  • richtig ists, wenns funktioniert. der rest ist künstlerische freiheit :D

    ok es gibt auch noch schlechten stiel. ein paar regelen sollte man dann doch einhalten. aber unterm strich ist das ergenis entscheidend, nicht der weg. ;)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!