[Scrymud] Developer Coordination, Goals, Organization, Standards, Extensability, blah de blah

[gingon at WANfear.com]

Quoting Justin Piper <justin at wanfear.com>:

> On Tue, 2002-02-05 at 15:12, Edward Roper wrote:
> > I'm not suggesting we introduce any sort of b.s. corporate style
> beuracracy
> > into this project as it would be highly unmotivating. This is after
> all an
> > open-source project written and maintained through a collaborative
> free-time
> > effort. I'm simply suggesting that we actually generate some
> collaboration.
> 
> Where I work, the development style has in the past been practically the
> antipathy of the methodology typically associated with corporate
> beuracracies.  It doesn't work so well.  There are some very good
> principles that can be skimmed off of a beuracratic development style,
> namely:
> * Waiting until you have finished the design before writing a single
> line of code
> * Peer review of proposed changes to the codebase prior to commit
> * Maintaining a development schedule, and actually sticking to it
> 
> As Ed says, this project is maintained during the free time of
> voulenteers, so I expect that that last one won't be too popular. 
> However, I submit that having a schedule is not necessaraly the same as
> having a fixed deadline.  The schedule exists primarily to help plan
> development in advance and to keep track of where we stand in on
> completing each part of the development.  If something takes longer than
> was anticipated, then the schedule is simply updated to reflect the
> revised estimated completion date.


more or less, i think the schedule should not be x will be finished on date, 
rather a will be done before anyone starts work on b. more of a list of 
priorities than an actual schedule.

of course, estimated completion times are still a good thing, but there 
shouldn't be a big rush to finish things.


> 
> > *       ALWAYS USE BRACES ON CONDITIONALS: even if they are 1 liners,
> i.e.
> >         This is another Grock said so.
> 
> I suggest allowing statements such as the following, provided they fit
> on an 80 column line in their entirety:
> 
> if (test) doStuff();
> 
> In situations where you have a lot of these, this becomes /much/ easier
> to follow than if every test takes up three lines, imo.
> 
> >         Note that the closing brace is empty on a line of its own,
> except in
> >         the cases where it is followed by a continuation of the same
> >         statement.
> > 
> >         do {
> >            body of do loop
> >         } while (condition);
> > 
> >         if ( x == y ) {
> >            ..
> >         } else if ( x > y ) {
> >            ...
> >         } else {
> >            ....
> >         }
> 
> In the case of the while, this is reasonable, however, if you put else
> blocks on a seperate line from the closing brace of the if, you can
> include a comment just above the else.
> 
> Additionally, I suggest the following conventions:
> * mixedCase identifiers, with class names Capitalized.
> * ALL_CAPS constants
> * Spaces before/after all keywords and operators, but...
> * ...No spaces between function names and their argument lists


as far as coding styles go, i like what loki has to say on it. but coding style 
isn't a big deal to me, i'll follow what ever you guys come up with.

one small thing i'd like to suggest is if there are 2 versions of the same 
function, one being a global function, one being in a class, use the class 
based one instead of the global one. for example crit.show() vs. show(). makes 
things easier to read.


> 
> > 3] Portability
> > 
> >         I havn't tried in a while but I would like to see ScryMUD
> compile and
> >         run on at least the following platforms:
> >                 * Linux
> >                 * FreeBSD
> >                 * Solaris
> 
> More to the point, ideally it should compile on any hardware platform
> that is reasonably well supported by the operating systems mentioned. 
> There is a problem of not being able to actually test all these
> platforms, but obvious stuff like assuming sizeof(int) == 4 should be
> avoided.


would be nice to look into supporting scry under win32 with cygwin also. not a 
priority, but since i'm in windows alot and use cygwin from time to time, i'd 
be willing to look into it if i have time.


> 
> > 4] Configurability
> > 
> >         After a quick glance I've found about 50 different MUD
> codebases and
> >         1,728 running MUD servers. Pretty much every one of this was
> written
> >         with one persons needs in mind, one type of environment, one
> set of
> >         rules. The licesnses vary and most of them are the results of
> building
> >         upon someone elses codebase. Personally I find this
> ridiculous.
> > 
> >         I believe that while we are in the process of redesigning core
> >         components of ScryMUD, we should make it as configurable and
> flexible
> >         as possible. Whether or not we plan on using a feature a
> particular
> >         way I believe wer should provide an option. This would not
> only make
> >         the codebase more useful to others who wish to run their own
> Worlds,
> >         but would also make the codebase more appealing to MUD
> developers
> >         working on other MUD's who would be inclined to submit
> patches, etc.
> >         back to the main effort.
> 
> I think it would be worthwhile to look at how MOO codebases operate. 
> Those systems are easily the most flexible, I'm sure something of value
> could be gleened from them.  Also, there is the decorator pattern and
> the composite pattern, both of which deal with creating complex objects
> from many smaller, specialized objects at runtime.  I belive that they
> would be well suited to defining the various objects in Scry's world. 
> This would have to be totally planned out in advance, though, or we
> could easily end up with a hugely complicated system that fails to meet
> the actual intended goal of more flexible objects.

can't think of much to say on this atm other than making it as easy to extend 
as possible is very important. not only makes it easier for someone else to use 
this codebase but also makes it easy for us to add stuff that we think of later 
on.


> 
> > 5] Modular code?
> > 
> >         This one is up in the air with me and I'm not sure if it would
> offer
> >         any benefit whatsoever, but I'm throwing it out there anyways.
> Dynamic
> >         loading modules via. libdl could offer the ability for
> "plug-ins".
> >         I've written code to do this before and it's not in the least
> bit
> >         difficult, or even tricky. It simplies requires a clear design
> from
> >         the start.
> 
> Well, loadable modules would allow you to trim out features you don't
> actually want without recompiling.  I don't think that's enough of an
> advantage right now to put up with the hassle, though.

would be nice if the client support code could be loaded as needed, which is 
what i had in mind when i originally wrote it, but never got around to actually 
implementing. wouldn't be worth implementing loadable modules for just this 
though.

dynamically loadable skills would also be a nice feature. you could add new 
skills, or even totally replace the existing skills with out much trouble.

> 
> Some miscelenious things I'd suggest:
> * Prefer compile-time checks to run-time checks.
> * STL is complete now, has more features than Grock's collection
> classes, _and_ can potentially take advantage of platform-specific
> optimizations.  The existing containers should be phased out.
> * More as I think of them/disagree with y'all. ^_^

never looked at STL so i can't really say much about it. but if it is as you 
say it is, then it looks like a good idea to use it.

--Gingon