home *** CD-ROM | disk | FTP | other *** search
/ Oakland CPM Archive / oakcpm.iso / cpm / gendoc / how2hack.msg < prev    next >
Text File  |  1983-09-09  |  4KB  |  87 lines
  1. HOW2HACK.MSG    11/15/81    Tom McCormick
  2.  
  3.    I'd like to suggest some guidelines for making changes to
  4. public domain programs on RCPM's.  I have spent a fair amount
  5. of time on a couple dozen RCPM's around the country in the last
  6. 12 months.
  7.  
  8.    I'd like to see some of the leading contributors write a
  9. .DOC file or two that could be permanently enlarged and refined
  10. to become an outline of good practices for the RCPM scene.
  11.  
  12.    Ward and Ben and Kelly and others have been writing messages
  13. and comments lately about the horrible job some hackers do to
  14. good programs.    I'm suggesting that we list some of the good
  15. practices and require (clearing house), or encourage them.
  16.  
  17.       1. The change should produce some benefit with BROAD
  18.      appeal. It should be TESTED for a few weeks prior
  19.      to submission. Dry running it on a friend or two
  20.      might also uncover something before hundreds of
  21.      people download it, only to have to download an
  22.      immediate "fix" or "improvement" a few days later!
  23.  
  24.       2. The source should indicate the author, version number,
  25.      as of date, and modifications since last version.
  26.      The purpose of the program should be immediately stated.
  27.      The comments should be in reverse chronological order,
  28.      and should be at the very front of the source so that
  29.      the 80 line typesq limit won't put 'em out of reach.
  30.  
  31.       3. The program should sign-on indicating the version #.
  32.  
  33.       4. If the program requires parameters passed to it, it
  34.      would be preferable to display a help menu or prompt
  35.      rather rather than abort, or exit the program. The 
  36.      reason for this is the growing use of menu programs;
  37.      they require a "second chance" to pass the parameters.
  38.  
  39.       5. A separate .DOC file is preferable. It should contain
  40.      the identical program name where possible, so that it
  41.      is clear what it belongs to.
  42.  
  43.       6. Program names of six characters or less will allow for
  44.      revision/version numbers to be appended later.
  45.  
  46.       7. If 2 or more programs are related, they should begin
  47.      with a common set of characters to force them to sort
  48.      together in directory listings.
  49.  
  50.      RBBENT27.BAS and RBBMIN27.BAS
  51.         is preferable to
  52.      FLS    SQ    USQ    and   CHANGES
  53.  
  54.       8. Give some thought (and effort) to avoiding use of words
  55.      or terms already used on non-CP/M systems. Programs have
  56.      been known to migrate, and the growing use of C and other
  57.      portable high level languages will only increase this.
  58.      Ask for help from SYSOPs or other users before setting
  59.      your pet name in concrete.
  60.  
  61.       9. DO NOT MAKE COSMETIC CHANGES to programs you send back
  62.      up to RCPMs.  The confusion far outweighs the "beauty".
  63.      Users do better with consistency than with constant change.
  64.  
  65.      10. Use DB's rather than equates for hardware dependant code
  66.      so that it can be readily patched with DDT, etc. MODEM7
  67.      is a nice example to follow, and all the bytes are in a
  68.      contiguous string right up front.  Nice.
  69.  
  70.      11. If you submit .BAS files to RCPMs, do that in ASCII so
  71.      they can be "TYPED". Nice to know if they're CBASIC or
  72.      MBASIC, or what.
  73.  
  74.      12. If a program is hardware dependant (Vector graphics), or
  75.      release dependant (ver 1.4 only?), or language dependant
  76.      (M80 but not MAC), this should be indicated in the filename,
  77.      or in the .DOC file right up front.
  78.  
  79.  
  80.     -------------------------------------------------------------
  81.  
  82.     Well, I'll quit now. Give everybody else a chance to hack
  83.     this up too.  Have at it.
  84.     Tom McCormick    Houston
  85.  
  86.     -------------------------------------------------------------
  87.