[MUD-Dev] Re: My vision for DevMUD

ApplePiMan at aol.com ApplePiMan at aol.com
Tue Nov 3 20:32:03 New Zealand Daylight Time 1998

At 11/3/98 4:43 AM Robert Woods (rwoods at honors.unr.edu) altered the 
fabric of reality by uttering:

[documenting code]

>Well, there are two ways to accomplish it.  One is to require that any code
>submitted for approval must be well-documented.  This will be a pain for the
>"benevolent dictator" to moderate, because he/she must then check all code
>to make sure it is documented, and must send back code, no matter how good
>or necessary, for documentation.
>Another possibility is to have a few people whose job is primarily to look
>at and document code.  These people would be given the code and would review
>it, doing whatever documentation is necessary.  If they have any questions,
>they bug the programmer.  Of course, these people must be familiar with
>programming, and if they're able to understand what's going on with the
>code, they would be better used in MAKING code.

I think that might be arguable... <g> I, for one, could follow and 
document code that was far more complex than any I could write. Mind you, 
I'm not arguing we should adopt this method; but some of us who are not 
first-rate coders could probably be as effectively employed that way as 
in writing fresh code.

>A third option, although difficult, is to brainwash programmers..."I want to
>make well-documented code."  Of course, one would think that people trying
>to work on a project such as this would already have that ingrained...or at
>least we would hope.

I think trusting coders to document their own code is our best bet. But 
if documentation of certain areas is not "up to snuff", throw the code at 
those, like me, who are marginally productive in producing new stuff and 
let us have a go at it.


Rick Buck, President and CEO  <mailto:rlb at big-i.com>
Beyond Infinity Games, Inc.
See you in The Metaverse! <http://www.big-i.com>

More information about the MUD-Dev mailing list