Back then, I was a Sinclair Spectrum user. Magazines like Your Sinclair and Sinclair User tended to only print code using Spectrum basic, so no porting was needed.
One of the problems with learning from this kind of code is that it tends to be golfed to heck, to make it faster to type in, and take fewer column inches (and so be more likely to be published!), so they would generally be a great blob of raw numbers in DATA statements that would be POKE'd into memory. If you typoed... well, debugging wasn't going to be a thing for you there. If you were lucky, the code checked some checksums so it told you what line your error was.
Instead, you'd carefully go through everything you typed character by character, and see where you'd slipped up.
Sometimes, the program just didn't work, and you could find no problem. Perhaps you typoed. Perhaps there was a printing error. You never found out.
Edit: I hunted down some Spectrum type-ins. Found a couple of good archives at http://www.users.globalnet.co.uk/~jg27paw4/type-ins/typehome.htm and https://www.computinghistory.org.uk/cgi/archive.pl?type=Listing&platform=ZX%20Spectrum which let me nostalgically revisit my past.
I feel my memory has been tainted by remembering best the last few years before the magazines died and I got my first PC. In that period, the type-in code had almost disappeared from the magazines. Any interesting programs were included on the cover tape rather than devoting column inches to them, and in print they were mostly only publishing "pokes" to hack cheats in games, which were mostly just blocks of DATA statements. If debugging a program was hard, debugging a hack into another program was essentially impossible without a Multiface (an awesome dongle for the Spectrum that let you debug memory in real time). Eventually the pokes, too, made their way to the cover tape.
Looking at the archived type-ins, I realize that yes, I did learn a lot of my first steps of programming, and formed my first early opinions about things like programming style, from type-in games.
I wish I still had my old tapes and 3 inch floppy disks (not 3.5 inch!)
This all reminded me of another source of type-ins, and coding knowledge: books! These "teach yourself BASIC" style books were in most libraries, and DID have the traits that the OP described: you'd need to convert from whatever flavor of BASIC the book was written in, to Sinclair Basic. And they'd teach you, in some way, about the language as you went. Even once you were comfortable with BASIC, you could usually pick up a few good tips and patterns from paging through a book and reading the listings.
Here you can see a Spectrum type-in that illustrates some of those tricks. There's lots of DATA lines, for graphics, coordinates, audio, and at the end, Z80 ASM for the monster AI.
Other than the impenetrable monster AI, the code is densely golfed but makes sense. Reading and understanding it took me a few hours today.
Main game loop is 100-300.
100-150 user input (keys left=5, right=8, ladder=0), detect collision with monsters and screen edges, picking up barrels, and dropping them into goal in the bottom right. Call ladder climb, or call die, or handle timer.
200-260 animate ladder climb subroutine.
300-310 handle timer, then go to die, or loop back to user input.
400-510 capture barrel: update score, add more monsters, then go to level setup.
700-730 die by monster, wall, or timeout. Decrement lives then go to begin play, or restart program.
1000-1001 Game initial setup: init vars, call mem setup, then go to level setup.
1002-2270 Level setup: init timer, score, floors, barrels, monsters, then go to begin play.
2275-2500 Begin play from new level or respawn, then go to user input.
9500-9510 Mem setup subroutine. Remap user characters (A=ladder, B=player, C=monster, D=barrel, E=player with arms raised), and Load in monster AI Z80 code, then return to game initial setup.
Tricks I might pick up from reading code like that, are things like:
- using
-SGN(x) to cap the variable x between bounds (line 125);
- using ATTR, the colors of the current coordinate, for item and collision detection, by ensuring the player is the only one with the default attributes (line 100)
- using empty loops for delays (line 2405: tsk, very bad form!);
- and using GOTO instead of GOSUB when the return from the subroutine could skip a few lines (lines 200-260 skip two lines of checks in the user input that can't happen on ladders).
- Using the #1 and #2 params to PRINT so that the full screen can be used as a display (A Spectrum quirt: #1 prints to the bottom two lines of the screen, typically reserved for input).
- It pulls a trick with DATA on line 410 that stores coordinates for a display of captured barrels. The DATA's read from line 400, but the ones that have already been captured are first read in the level setup code at line 2280, so the READ pointer becomes a method of tracking progress.
- Massive reuse of variables, especially l=line, x=column and i=loop iterator.
- Store the player's avatar in a variable (m$) so it needn't check the bf flag every time it's drawn.
- Mark flags obviously with a Polish-like naming convention like bf/mf/lf (second character is f for boolean flag: monster flag, ladder flag). Not all vars use Polish, though: other vars are sc=score, ba=barrels, no=number of monsters.
