home *** CD-ROM | disk | FTP | other *** search
/ Fresh Fish 5 / FreshFish_July-August1994.bin / bbs / docs / blazehumor-1.0.lha / BlazeHumor-1.0 / Articles / 77_ProgrammingTips < prev    next >
Text File  |  1993-10-25  |  8KB  |  163 lines
  1.               10 AMIGA PROGRAMMING TIPS FOR THE REAL WORLD
  2.  
  3.                            Daniel J. Barrett
  4.                     Department of Computer Science
  5.                      University of Massachusetts
  6.                          Amherst, MA  01003
  7.                                  USA
  8.  
  9.                     E-mail: barrett@cs.umass.edu
  10.  
  11.     When Sergio Ruocco kindly asked me to contribute an article for these
  12. proceedings, I was very excited.  You see, I am an Amiga programmer too, and
  13. I have always dreamed of sharing my favorite programming tips at a
  14. conference full of experts!  The following article explains the ten most
  15. effective secrets for writing the ultimate Amiga program.
  16.  
  17.     For years, I've been reading millions of "programmer tips" articles
  18. in magazines, and personally, they make me sick.  No matter how clever the
  19. suggestions are, the authors always forget one very important point: if you
  20. are the programmer, then YOU ARE IN CHARGE.  Who CARES what the users think?
  21. If they don't like the way your program works, then let the ignorant fools
  22. write their own.
  23.  
  24.     With this in mind, I hereby present 10 programmer tips for the real
  25. world.  These are GUARANTEED to triple your productivity within 24 hours!
  26. Well, at least double it.  Or maybe cut it in half.  I forget.  But they will
  27. DEFINITELY help you; and if they don't, then you have my permission to throw
  28. these conference proceedings off a cliff and go join a religious cult.
  29.  
  30. (1) Don't plan your program in advance.
  31.  
  32.     Seriously, now... planning your program in advance is a total waste
  33. of time, and you know it.  Programming is an art form; and as sensitive
  34. artists, we must not be rushed into making decisions.  Will your program
  35. have a command-line or a graphic interface?  An ARexx port?  Will it be a
  36. database or a shoot-em-up game?  IT DOESN'T MATTER.  Just start coding, and
  37. worry about these insignificant details later.
  38.  
  39.     Even better, just start COMPILING... even before you have decided
  40. what your program is going to be.  Running the compiler or assembler a lot
  41. before you write any code will "warm up" your computer, and your software
  42. will have fewer bugs.  Trust me.  I ran my compiler 50 times last night
  43. without writing a single line of code, and so far my program has no bugs.
  44.  
  45. (2) Don't use the standard libraries.
  46.  
  47.     No real Amiga programmers use the stuff in LIBS:, or even Kickstart.
  48. It is FAR better to do all the work yourself and create an entire operating
  49. system from scratch.  This is REALLY impressive.  Your users will be stunned,
  50. and beautiful, sexy movie stars from around the world will travel thousands
  51. of miles to ask you out on dates.  Believe me, it's true.  I have a hot date
  52. with Cindy Crawford tonight because she loves my custom Exec list structures.
  53.  
  54. (3) Don't use "Make".
  55.  
  56.     Face it:  "Make" is for wimps.  REAL programmers KNOW which files
  57. are compiled and which ones aren't.
  58.  
  59. (4) Keep your user interface inconsistent.
  60.  
  61.     Who needs standards?  It is much better if every programmer invents
  62. his/her/its own user interface style, for three reasons.  First, it lets
  63. programmers be creative and helps to relieve stress.  Second, by making your
  64. program harder to use, it gives users valuable practice in working with
  65. difficult software.  Finally, we know that users are incredibly lazy
  66. creatures, and a little suspense keeps them in shape.  It's for their own
  67. good.
  68.  
  69.     So, don't be afraid to take some chances and make your interface
  70. really unique!  Instead of the right mouse button, use double-clicks to bring
  71. up menus.  Make your window resize gadgets act like close gadgets, and
  72. vice-versa.  Fix your text color and background color to be the same.  Be
  73. inventive, and your users will thank you for it.
  74.  
  75. (5) Hard-code your fonts.
  76.  
  77.     Why waste time making your program font-sensitive?  Hey, if "Topaz 8"
  78. is good enough for Commodore, it's good enough for everyone.  Or to make your
  79. programs look truly unique, I recommend using a really obscure third-party
  80. font (e.g., "WalrusBreath 91-point").  If the font isn't found in the user's
  81. FONTS: directory, then your program should put up a polite, friendly
  82. requestor and then crash.
  83.  
  84. (6) Hard-wire all your screens to 320x256 PAL (or 320x71 in NTSC).
  85.  
  86.     Some users will complain if programs don't take advantage of
  87. overscan, but they are just whiners.  YOU wrote the program, so YOU will
  88. know which screen sizes are best.  And while you are at it, you should also
  89. hard-code the palette and number of bitplanes.  That will teach those pesky
  90. users a lesson.
  91.  
  92. (7) Use heavy copy protection.
  93.  
  94.     Especially for freeware, where dongle protection is a must.
  95.  
  96. (8) Ignore playability.
  97.  
  98.     Hey, if the users can't play your game, they're wimps.  Let them
  99. go play checkers instead.
  100.  
  101. (9) Write all of your documentation at the last minute.
  102.  
  103.     If you want complete freedom in your programming, it simply is not
  104. practical to write your manuals early.  Wait until later:  say, after the
  105. program has been shipping for a few months.  By then, you will have a good
  106. idea of what the program can do, and you're reading to create the docs.
  107.  
  108.     If possible, avoid paper manuals entirely and document the whole
  109. program in a "README" file on the program disk.  I know that some users don't
  110. like README files because the information often isn't presented in a natural
  111. order.  So, if you feel obligated to please your users, I recommend running
  112. your README file through C:Sort.
  113.  
  114.     Another option is to use Commodore's AmigaGuide format.  This is an
  115. excellent idea, but many programs do not take full advantage of this
  116. hypermedium.  In most AmigaGuide documents I've seen, fewer than 10% of the
  117. words appear as buttons.  For maximum benefit, EVERY word should be a
  118. button... even the AmigaGuide window title bar.
  119.  
  120.     If you do decide to use on-line documentation, you might consider
  121. putting it on a BBS instead of on disk, so you can make changes to it easily.
  122. If you are feeling nice, you can even tell your users the BBS telephone
  123. number, but this is not required.  (To make things easier, put the phone
  124. number in the documentation file.)
  125.  
  126. (10) Don't use the Commodore Installer.
  127.  
  128.     When it was introduced, the Commodore Installer was a significant
  129. advance over manual installation.  Instead of forcing the user to make
  130. Assigns and execute obscure "Copy" commands, the Installer guides the user
  131. through a friendly set of easy-to-understand prompts, such as "Please insert
  132. directory 'READ/WRITE_ERROR' in any drive."
  133.  
  134.     Nowadays, however, the Installer has been replaced by more powerful
  135. utilities.  The best one available today is called BLAZE-INSTALL, created by
  136. those ultimate programmers at BLAZEMONGER INCORPORATED.  BLAZE-INSTALL is so
  137. easy to use that you don't even need a single mouse-click to install the
  138. software.  Heck, you don't even have to insert the installation disk!  Just
  139. unwrap the package, and BLAZE-INSTALL does the rest.  If a file is missing,
  140. BLAZE-INSTALL automatically generates it... even complete programs!  In
  141. fact, BLAZE-INSTALL is the last program you (or anybody) will ever need to
  142. buy, since it can create any other piece of software in existence.  So I
  143. guess we programmers should all just go home and find other jobs.
  144.  
  145.  
  146.     Well, those are my 10 most useful Amiga programming tips.  I hope
  147. that you found them useful, or at least mildly destructive.  If you'd like
  148. further information on Amiga programming, I strongly recommend the books
  149. "Amiga Tips, Tricks, and Terrorism" by Ira Sadist, and "Kicking the Hell out
  150. of Kickstart" by Pal Booter.  Have fun!
  151.  
  152. ==============================================================================
  153.  
  154. Daniel J. Barrett, a doctoral student in computer science at The University
  155. of Massachusetts, is an Amiga humorist on USENET and the inventor of
  156. BLAZEMONGER.
  157.  
  158. ---
  159. Copyright 1993 by Daniel J. Barrett.  All rights reserved.
  160. This article may be freely distributed as long as it is distributed in its
  161. entirety.  It may not be included in any publication without the written
  162. permission of the author.  So nyaaah.
  163.