> >low level string functions, for instance, have several functions doing
> >similar tasks.
>
> Like?
char *one_argument(char *argument, char *first_arg);
char *one_word(char *argument, char *first_arg);
char *any_one_arg(char *argument, char *first_arg);
char *two_arguments(char *argument, char *first_arg, char *second_arg);
void half_chop(char *string, char *arg1, char *arg2);
Five functions (at least) for doing more or less the same thing. This
can be reduced to two or three functions which provide more robust
functionality. I've done so in my code and will post a snippet if
anyone would like (basically I have a function that splits a string
into words, optionally respecting quotes and double quotes, and stores
the results globally).
> >6. Code appearance. Circle is in most cases readable; however, there
> >are times it isn't. In particular, the use of typedefs can simplify
> >things.
>
> Working on some... (room/mob/obj/etc types) Feel free to suggest more.
I've got OBJ_DATA, CHAR_DATA, ROOM_DATA, etc. I believe Envy uses the
same naming scheme. I have a sed script I've used to replace my
code's references to the full 'struct char_data' names that I would be
glad to give you if you're interested.
> >Also, we need to get rid of ACMD and ASPELL (something I did straight
> >off). They are a convenience in the initial writing of a command or
> >spell, but they are an abuse of notation, so to speak, and can cause
> >problems with symbolic debuggers as well as cross referencing programs.
>
> They are quite handy to figure out what is a player-visable command and
> what isn't. I'd say fix the debugger or cross reference program.
I agree, fix the other programs. However, using ACMD and ASPELL are
ugly. They redefine the language and its grammar. They obscure the
true declarations. Preprocessor macros weren't meant for this kind of
thing.
Now, admittedly, my objection stems from a language purist's point of
view. But we shouldn't bastardize the language unless we absolutely
have to. Using the full declarations is no huge strain :)
> >Generally, for every time you're lazy when you
> >code something, you'll spend three hours later fixing a shortsighted
> >mistake or some other issue ;)
>
> I work hard to be lazy. In other words, if I can make a script to automate
> some task I do all the time, I do. I wouldn't call ASPELL() being lazy,
> it's definitively declaring what the function is, and what arguments it
> gets. The spells and commands would not work if they took different
> arguments. (function pointers)
I once read somewhere the definition of a good programmer is one who
knows just how lazy he can be without breaking something. Laziness is
a time-honored tradition among programmers, one that I subscribe to
fully. I should have added the word "unnecessarily" up there :) ACMD
and ASPELL hide the declarations and change the grammar of the
language. I'm not saying change the definitions, or let some commands
take different parameters. I just mean that we shouldn't use macros
like this.
> >Also, it would be nice if all the code conformed to one style. I have an
> >indent script I use for my own (though I don't need it often since I let
> >emacs do my formatting for me) which reformats all the code to a specific
> >style. It's quite useful.
>
> Most of it was formatted with the following 'indent' parameters:
>
> -kr -i2 -di0 -npsl -nfc1
>
> (Saved the mail message where Jeremy said that, you can find it somewhere
> in the mail archives if you don't believe me.)
Ahh I didn't realize that. I definitely believe you, and it's a good
idea :) It has been quite a while since I looked at stock circle; my
own code base is quite different now.
> >7. Linked lists. The current linked list support is, well, somewhat
> >dirty. Imbedding next elements into all the structures then using the
> >REMOVE_FROM_LIST macro is extremely ugly. We need to get a simple
> >linked list library written (a fairly simple task), or use one out
> >there.
>
> You don't have to use 'next', you can name it whatever you want. The
> REMOVE_FROM_LIST is simple and works, especially considering you cannot use
> a function and this is not C++.
I'm saying don't have _any_ pointers like next in the structures.
Instead have a linked list library using structures like
struct ll_data {
struct ll_data *next;
void *data;
};
Then perhaps use wrappers to properly cast the data argument. We
definitely can use functions, just not in the way above.
Also, along this line, we should perhaps consider restructuring the
mob/player structures. Here would be an example that would clean
things up a bit while still allowing for flexibility. This is nothing
new in general, but I think it is something Circle would benefit
from. It is loose inheritence, so to speak.
struct char_data {...}; /* character data common to players/mobs */
struct player_data {
struct char_data ch;
...
};
struct mob_data {
struct char_data ch;
...
};
That way, we can refer to players by char_data pointers, and also
refer to them by their own type. Add a magic byte to the char_data
structure so that the code can distinguish. This is basically how C++
internally handles single inheritance. The downside is we don't have
compile-time strong typing, but that isn't so horrible in this limited
case.
> >I personally use the singly linked list class from glib (a
> >subcomponent of gtk, which provides a large amount of common C
> >algorithms and structures, including hashes, lists, and I believe
> >trees), which is exactly what we need. The only downside is that,
> >though glib itself is cross-platform I believe, gtk probably doesn't
> >port to Win32 yet.
>
> CircleMUD is a base, not the end-all-be-all MUD.
Certainly it is only a base, and I definitely don't wish to throw the
kitchen sink in. But we should provide a strong foundation of library
routines. Don't add, say, mounts and mounted combat; they are
genre-specific. Do add associative arrays (hash tables). Facilitate
future expansion.
--
James Turner turnerjh@xtn.net
http://www.vuse.vanderbilt.edu/~turnerj1/
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST