home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / rec / games / mud / misc / 1745 < prev    next >
Encoding:
Text File  |  1992-12-29  |  2.8 KB  |  50 lines
  1. Newsgroups: rec.games.mud.misc
  2. Path: sparky!uunet!cs.utexas.edu!uwm.edu!psuvax1!atlantis.psu.edu!handel!stine
  3. From: stine@handel.psu.edu (Jeffrey Stine)
  4. Subject: Re: Note to any fellow DikuMUD coders...
  5. Message-ID: <e961H_8!pb@atlantis.psu.edu>
  6. Sender: news@atlantis.psu.edu (Usenet)
  7. Organization: Penn State University
  8. References: <Bzy9ps.3FF@math.okstate.edu> <mj22Hvjmpb@atlantis.psu.edu> <1992Dec28.231606.6328@cs.mun.ca>
  9. Date: Tue, 29 Dec 92 07:55:03 GMT
  10. Lines: 38
  11.  
  12. In article <1992Dec28.231606.6328@cs.mun.ca> matthew@cs.mun.ca (Matthew J. Newhook) writes:
  13. >stine@handel.psu.edu (Jeffrey Stine) writes:
  14. >> And as I believe was more or less pointed out earlier, programming practices
  15. >>are much a matter of opinion and have less to do with being "good" or "bad".
  16. >
  17. >Well, I certainly disagree with this.  There is a significant
  18. >difference between bad code and good code. And most of this is _not_
  19. >subjective.  If the code is spaghetti code then it is very hard to work
  20. >with, let alone alter.  All you have to do is work with some terrible
  21. >code for a while and you will get irritated and start cursing this
  22. >'terrible' code.  Of course you do work with the diku code don't you :)
  23. >
  24.  Ack, I better clear something up before everyone begins to think I like or
  25. promote poor programming practices.  Anyone that has worked with me knows
  26. that I am very finicky about code I will accept.  I don't believe there is
  27. room for such things as spaghetti code, inefficient code or even poorly
  28. defined variables (I like something that can be easily read by anyone).
  29. I strongly belive in keeping code modular, as portable as possible and
  30. all that.  However I believe that people have different ideas about how
  31. to go about these sorts of things and that one person may call another's
  32. style good or bad.  This labeling is what I was getting at ... when it
  33. becomes a matter of habit/style that differs and not whether the basis
  34. is sound, then it is nothing but opinion.  And it is fairly silly to call
  35. someone a "bad" programmer based on a few hacks.  I would prefer to use
  36. the ideas presented, rather than lecture the person on how they did something
  37. wrong.
  38.  Despite fairly good reasons presented why using inet_nota() might be better
  39. than writing your own version: In my mind there is a world of difference
  40. between that and non-structured or non-modular code.  One may label a certain
  41. style "bad" according to your tastes and evalutions, but that doesn't
  42. necessarily make it poor programming except perhaps for your own uses.
  43.  
  44.  And incidentally, I don't curse poor code I intend to use so much as
  45. I make it better to suit my own needs (which I did tenfold with diku).
  46. But then my expertise lies within the realm of analysis so I am much
  47. better equipped to deal with sorting it out.  The rest of you must, alas,
  48. make do with only "good" code. :)
  49.  
  50.