Negativbeispiel

[CPCIak]

Anbei mal ein Negativbeispiel:
(-) in die erste Zeile gehört normalerweise eine kleine Beschreibung (REM Bestimmung CRTC TYP)
(-) keine Quellenangabe oder Hinweise über den Autor
(-) Zeilennummerierung nicht fortlaufend
(-) Zeilenumbrüche in Zeile 100!
(-) keine Checksumme am äußeren Rand

Code Select Expand

5 MEMORY 16382
10 DIM c(111)
20 FOR i=1 TO 111:READ c(i):NEXT i
30 k=16384:FOR i=1 TO 111:POKE k,c(i):k=k+1:NEXT i
40 CALL &4000
50 a=PEEK(&3FFF)
60 PRINT:PRINT:PRINT "CRTC Type =";a
70 END
100 DATA 243,42,56,0,34,103,64,33,251,201,
34,56,0,6,245,237,120,15,210,15,64,237,
120,15,210,21,64,251,118,33,75,0,44,124,
181,194,32,64,237,120,15,218,47,64,175,
24,42,118,118,118,243,237,120,15,210,51,
64,1,2,188,237,73,1,50,189,237,73,251
110 DATA 118,118,118,118,118,118,118,6,
245,237,120,15,210,87,64,62,1,24,2,62,2,1,
2,188,237,73,1,46,189,237,73,50,255,63,
33,0,0,34,56,0,251,201,201

Bitte berücksichtigt diese Punkte bei den von Euch veröffentlichten Listings, Danke!

[Octoate]

Hinzu kommt, dass ich die Bytes immer hexadezimal angeben wuerde, da sie dann lesbarer werden und immer nur zwei Zeichen lang sind. Die Anzahl von Werten pro Zeile sollte ausserdem so eingeschraenkt sein, dass kein Umbruch stattfindet.
Bei Data-Zeilen sollte auch unbedingt eine Checksumme ueber die eingelesenen Werte gebildet werden (entweder ueber den alten Checksummer der CPCAI oder ueber eine eigene Routine im Quellcode). Praktisch waere die Checksumme pro Datazeile damit bei einer fehlerhaften Programmeingabe auch automatisch die Zeilennummer ausgegeben werden kann. Das waeren dann z.B. 8 Datenwerte und dahinter die Checksumme. Die Werte aufaddiert bilden dann die Checksumme und koennen ueberprueft werden.

[Devilmarkus]

Das Listing wurde von einem Emulator "ausgedruckt".
Dort sind natürlich Zeilenumbrüche drin.
Diese muss man manuell entfernen.

Code Select Expand

5 MEMORY 16382
10 DIM c(111)
20 FOR i=1 TO 111:READ c(i):NEXT i
30 k=16384:FOR i=1 TO 111:POKE k,c(i):k=k+1:NEXT i
40 CALL &4000
50 a=PEEK(&3FFF)
60 PRINT:PRINT:PRINT "CRTC Type =";a
70 END
100 DATA 243,42,56,0,34,103,64,33,251,201,34,56,0,6,245,237,120,15,210,15,64,237,120,15,210,21,64,251,118,33,75,0,44,124,181,194,32,64,237,120,15,218,47,64,175,24,42,118,118,118,243,237,120,15,210,51,64,1,2,188,237,73,1,50,189,237,73,251
110 DATA 118,118,118,118,118,118,118,6,245,237,120,15,210,87,64,62,1,24,2,62,2,1,2,188,237,73,1,46,189,237,73,50,255,63,33,0,0,34,56,0,251,201,201


Wobei ich nicht verstehe, wieso so viele Umbrüche im Listing sind...
JavaCPC Drucker macht bei den langen Zeilen nur jeweils 1 Umbruch:

[CPCIak]

Bei dem Beispiel ging es darum den Leuten zu zeigen, daß die Listings bestimmten Formalien entsprechen sollten.

[TFM]

Dafür ist es kurz, kompakt, effizient und enthält keinen Müll. Für mich ein rel. guter Code, den man aber noch besser optimieren könnte. Nur dann würden hier einige Leute einen Schreikrampf bekommen, da sie gar nichts mehr lesen könnten ;-)))

Anbei mal ein Negativbeispiel:
(-) in die erste Zeile gehört normalerweise eine kleine Beschreibung (REM Bestimmung CRTC TYP)
(-) keine Quellenangabe oder Hinweise über den Autor
(-) Zeilennummerierung nicht fortlaufend
(-) Zeilenumbrüche in Zeile 100!
(-) keine Checksumme am äußeren Rand

Code Select Expand

5 MEMORY 16382
10 DIM c(111)
20 FOR i=1 TO 111:READ c(i):NEXT i
30 k=16384:FOR i=1 TO 111:POKE k,c(i):k=k+1:NEXT i
40 CALL &4000
50 a=PEEK(&3FFF)
60 PRINT:PRINT:PRINT "CRTC Type =";a
70 END
100 DATA 243,42,56,0,34,103,64,33,251,201,
34,56,0,6,245,237,120,15,210,15,64,237,
120,15,210,21,64,251,118,33,75,0,44,124,
181,194,32,64,237,120,15,218,47,64,175,
24,42,118,118,118,243,237,120,15,210,51,
64,1,2,188,237,73,1,50,189,237,73,251
110 DATA 118,118,118,118,118,118,118,6,
245,237,120,15,210,87,64,62,1,24,2,62,2,1,
2,188,237,73,1,46,189,237,73,50,255,63,
33,0,0,34,56,0,251,201,201

Bitte berücksichtigt diese Punkte bei den von Euch veröffentlichten Listings, Danke!