Just a sample of the Echomail archive
Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.
|    CBM    |    Commodore Computer Conference    |    4,328 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 2,267 of 4,328    |
|    Pekka Takala to Herr Doktor    |
|    Re: Looking moremore optimizations!    |
|    10 Nov 18 19:10:16    |
      On 08.11.2018 20:04, Herr Doktor wrote:       > I realize I'm jumping into the middle of a conversation and it isn't       > my intention to derail it. What jumps out at me from your code is the       > lack of comments. It's been years since I did any programming but       > when I did I always commented extensively. I also use many small       > modules rather than one huge source file. Then the main program       > becomes just the flow of logic and decision with calls to the       > appropriate modules as required.       >       > I find that writing in this way makes things much easier all the way       > around, all aspects.              Also, creating the game as modules helps you if you exceed the usable       memory. You can then split things if they do not depend on each other       and load them from disk/tape/cartridge when needed. If the code is in       one big snippet, the splitting is WAY more difficult to do if needed.              Commenting is important- what does what. The comments DO NOT take any       space after compiling, the compiler just skips them completely. It helps       you to read the code afterwards and makes guessing less needed. And       also, if you make the code as modules, you can support various hardware       easier since you can load various pieces to memory depending on hardware.              And, when you have tasks those are common, in their own files, you       lessen the trouble of getting hard-to-repair bugs. You can parametrise       the functions so that you can use same code to little various tasks,       still being similar. For example, you can read keyboard with its own       function. If parametrised, you can restrict the keys needed to read, so       you do not need to check them in later code since the keyboard code does       that for you already. This method makes the code less prone to exploits,       although on commodore platform the exploit avoiding is not so important       than on platforms those are connectable to Internet. Still practicing       this makes you better coder on other platforms also.              --- SoupGate-Win32 v1.05        * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca