Hallo Besucher, der Thread wurde 15k mal aufgerufen und enthält 59 Antworten

letzter Beitrag von Fröhn am

C-Kurs, Abend 4 - Verbesserungsvorschläge

  • ?ASC("<TAB>")
    9


    READY.

    Danke! Das ist interessant. Da liegt beim C64 ja "entriegele Shift-C=". Hab' das gleich mal im Emulator ausprobiert (ich habe keinen echten C128 und sowieso nur einen einzigen C64, und das auch noch ein Aldi :rotwerd:): Beim C128 kann man "Schift-C=" (also die Groß/Klein-Umschaltung) gar nicht sperren.


    Den Unterschied könnte man vielleicht mal in den PetSCII-Artikel im Wiki einbauen. Muss mich da vielleicht doch mal anmelden. ...

  • Beim C128 gibt es übrigens noch einige andere PETSCII-Geschichten, die beim C64 nicht vorhanden sind. Z.B. "Bell" oder auch "ESC". Leider hab ich hier kein C128 Handbuch, darin findet sich eine entsprechende PETSCII-Tabelle.

    Tatsächlich: "PRINT CHR$(7)" gibt einen wunderschönen Pieps aus. OK, das sollte irgendwie noch in den Absatz über \a und \t rein, dass die (Nicht-)Konvertierung für den 128 durchaus Sinn ergibt, für den CeVi aber leider nicht, also nicht sehr plattformunabhängig. ...


    Und um die C64-Wiki-Seite sollte man sich wirklich bei Gelegenheit mal kümmern. ...

  • ...
    - deutsch variablen- oder funktionsnamen. ihbähpfui. auch das sollte man garnicht erst zeigen, denn sonst wird das zur gewohnheit. es gibt nichts schlimmeres als in einem source rumguckn zu müssen wo die funktionen nach irgendeiner landessprache benannt sind die man nicht beherrscht. darum von anfang an: englisch.
    - gleiches gilt für kommentare, vielleicht sogar noch wichtiger. auch da tut man sich nur selber einen gefallen wenn man die einfach konsequent immer in englisch macht.
    ...

    Sprechende Funktions-, Variablennamen sowie Kommentare sind wichtig, doch warum sollte man in einem Kurs, der in einer Landessprache gehalten wird, nicht auch den Code in eben dieser welchen gestalten?
    Bei internationalen Projekten macht es sicher Sinn, sich auf Hochchinesisch, Hindi oder Englisch zu einigen (Reihenfolge der meistgesprochenen Sprachen), hat man aber 100 Entwickler, die sich alle in einer Sprache austauschen, nur Code in einer anderen Sprache, klingt das doch ein wenig albern, oder?
    Also wenn englische Variablen, dann auch englischer Kurs. Else ist albern. ;-)

  • (...) warum sollte man in einem Kurs, der in einer Landessprache gehalten wird, nicht auch den Code in eben dieser welchen gestalten? (...)
    Also wenn englische Variablen, dann auch englischer Kurs. Else ist albern. ;-)


    das sehe ich ähnlich.


    ausserdem sollte in diesem kurs der *spass* im vordergrund stehen. ohne natürlich falsches wissen zu vermittlen. langweilige bücher, die alle (un)tiefen der programmiersprache c ausloten, gibt es doch in hülle und fülle ...

  • Hallo, da bin ich wieder.


    @heptasean: Danke für den Exkurs und die anderen Korrekturen. Baue ich bei Gelegenheit ein.


    Wg. Deutsch vs. Englisch für Variablen und Kommentare scheint es ja unterschiedliche Meinungen zu geben.


    In Zukunft werde ich in dem Kurs die Variablen Englisch benennen, damit der Code nicht zu murksig aussieht. Die Kommentare lass ich aber Deutsch, um das Verständnis so einfach wie möglich zu machen. Das ist wahrscheinlich ein guter Kompromis zwischen Ästhetik und Verständlichkeit.


    Gruß,
    Thomas

  • Hi,


    ich würde mir zur Auflockerung der ganzen harten Themen die jetzt folgen, das Ansprechen des Bildschirmspeichers wünschen. Wir haben jetzt gelernt einzelne Zeichen auszugeben, sogar Zahlen in Zeichen umzuwandeln und auszugeben. Laßt uns mal Bildschirmadressen anspringen und Zeichen irgendwo gezielt ausgeben. Das reicht doch fast schon für Pong, was meint Ihr?


    Gruß, Worf

  • Hi,


    ich würde mir zur Auflockerung der ganzen harten Themen die jetzt folgen, das Ansprechen des Bildschirmspeichers wünschen. Wir haben jetzt gelernt einzelne Zeichen auszugeben, sogar Zahlen in Zeichen umzuwandeln und auszugeben. Laßt uns mal Bildschirmadressen anspringen und Zeichen irgendwo gezielt ausgeben. Das reicht doch fast schon für Pong, was meint Ihr?


    Gruß, Worf


    Guter Einwurf, aber dafür brauchen wir Pointer. Das halte ich didaktisch für zu früh. Wir sollten auf jeden Fall zuerst die Kontrollstrukturen abschliessen, das Casting abhandeln und auf Pointer eingehen. Gerade die letzten beiden Punkte sind meiner Meinung nach wichtig, um die Besonderheiten der hardwarenahen Programmierung richtig verstehen zu können. Da passen dann auch IMHO Pokereien im Bildschirmspeicher. Meine 2 Cent...


    P.S. Wenn Du allerdings die Funktionen der conio.h meinst, habe ich nix gesagt. Die könnten den Spieltrieb animieren. :weg:

  • bevor man die leute mit pointern erschreckt :)


    Sind harmlose Tierchen, die nicht beissen.
    Die Aufklärung macher Klavierspieler, die den Pointerapparat erklären wollen ist schrecklich. :winke:


    Ansonsten nichts als reine Pokerei und Peekerei im cc65 mit einer vernünfigen Adressenvergebung. :bia


    Sind langsamer als die vordefiniertne POKE/PEEK im cc65, womit man reservierte Speicherbereiche vollmüllen kann.