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

[Justin Piper]

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.

> *       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

> 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.

> 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.

> 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.

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. ^_^