HOW2HACK.MSG 11/15/81 Tom McCormick I'd like to suggest some guidelines for making changes to public domain programs on RCPM's. I have spent a fair amount of time on a couple dozen RCPM's around the country in the last 12 months. I'd like to see some of the leading contributors write a .DOC file or two that could be permanently enlarged and refined to become an outline of good practices for the RCPM scene. Ward and Ben and Kelly and others have been writing messages and comments lately about the horrible job some hackers do to good programs. I'm suggesting that we list some of the good practices and require (clearing house), or encourage them. 1. The change should produce some benefit with BROAD appeal. It should be TESTED for a few weeks prior to submission. Dry running it on a friend or two might also uncover something before hundreds of people download it, only to have to download an immediate "fix" or "improvement" a few days later! 2. The source should indicate the author, version number, as of date, and modifications since last version. The purpose of the program should be immediately stated. The comments should be in reverse chronological order, and should be at the very front of the source so that the 80 line typesq limit won't put 'em out of reach. 3. The program should sign-on indicating the version #. 4. If the program requires parameters passed to it, it would be preferable to display a help menu or prompt rather rather than abort, or exit the program. The reason for this is the growing use of menu programs; they require a "second chance" to pass the parameters. 5. A separate .DOC file is preferable. It should contain the identical program name where possible, so that it is clear what it belongs to. 6. Program names of six characters or less will allow for revision/version numbers to be appended later. 7. If 2 or more programs are related, they should begin with a common set of characters to force them to sort together in directory listings. RBBENT27.BAS and RBBMIN27.BAS is preferable to FLS SQ USQ and CHANGES 8. Give some thought (and effort) to avoiding use of words or terms already used on non-CP/M systems. Programs have been known to migrate, and the growing use of C and other portable high level languages will only increase this. Ask for help from SYSOPs or other users before setting your pet name in concrete. 9. DO NOT MAKE COSMETIC CHANGES to programs you send back up to RCPMs. The confusion far outweighs the "beauty". Users do better with consistency than with constant change. 10. Use DB's rather than equates for hardware dependant code so that it can be readily patched with DDT, etc. MODEM7 is a nice example to follow, and all the bytes are in a contiguous string right up front. Nice. 11. If you submit .BAS files to RCPMs, do that in ASCII so they can be "TYPED". Nice to know if they're CBASIC or MBASIC, or what. 12. If a program is hardware dependant (Vector graphics), or release dependant (ver 1.4 only?), or language dependant (M80 but not MAC), this should be indicated in the filename, or in the .DOC file right up front. ------------------------------------------------------------- Well, I'll quit now. Give everybody else a chance to hack this up too. Have at it. Tom McCormick Houston -------------------------------------------------------------