Documenting softcode (gasp)
When I need something softcoded, especially a function, chances are I'll code it myself. Even if it exists. Even if it exists on the same MUSH. There are several reasons for that, but one's a fairly big one: Softcode is hard to read. Doubly so if you didn't code it. What's worse, since softcode doesn't have a function definition like you would in C or Python or whatnot, you don't have even the self-documentation that comes from variable names, and in fact you may have to dig deep to even see how many arguments a function takes, let alone determine which ones are optional. I've been wanting to do something about that for a while (read: at least 3 years), but this time I actually did come up with a partial solution.
Let's take a quick example. How many arguments does the following code take, and how many are optional? What do the arguments DO? What does the thing return anyway? (Please don't waste too much time on it.)
&FUN_DOCUMENT object=ifelse(hasattr(%0,1`cc),u(fun_parse_cc,lcstr(%1),xget(%0,%1`cc)),Function has no calling convention defined.)[if(%2,%r[if(hasattr(%0,%1`doc),u(fun_decorate,u(%0/%1`doc),first(xget(%0,%1`cc))),Function has no docstring.)])]
Still with me? Okay, now, how much easier is it to get the same info from this snippet of text, generated by my docf code:
Call: u(fun_document, <object>, <attr>, [full])
=> documentation (a string)
Let's see.. 2 args with an optional third. An object, an attr, and optionally something called 'full'. It returns some documentation, apparently. So 'full' might mean 'display full documentation' as opposed to a part of it?
How did I generate this snippet? Relatively easily:
&fun_document`cc object=object:attr:*:full r:string:documentation
docf object/fun_document
This says: I have arguments object and attr, the rest of the arguments are optional, the one optional argument is 'full'. It returns a string which represents documentation.
This is a nice start, but some things are still unclear. Let's change that.
&FUN_DOCUMENT`DOC object=Get the documentation of the ufun in OBJECT/ATTR. If FULL, output the docstring as well as the calling convention.
docff object/fun_document
That gets me:
Call: u(fun_document, <object>, <attr>, [full])
=> documentation (a string)
Get the documentation of the ufun in <object>/<attr>. If [full], output the docstring as well as the calling convention.
Note that it automatically transformed the uppercase arguments, marking them as mandatory or optional, as well as making them stand out. (And additionally it lets the docf code know those arguments are documented so it won't warn you about skipping them.)
With docf you have 2 times 2 options: docf with one f displays just the calling information (what's defined in the `cc attr). docff (with a second f for 'full') displays the docstring as well. On the argument side, you can specify obj/attr, or just an object to see the info for all documented functions. So you can go 'docf object' to get a quick reminder of what functions are available and roughly how they work, or 'docff object/attr' to get all the info for a specific function. Or even 'docff object' when you're learning how a new system works.
The system so far has a fair amount of features, but it does have two important limitations: First off, it's only meant for documenting ufuns, not commands or other things (though at least commands are clearer about their arguments). Second, it still requires someone to actually write the documentation, sadly ;) Though even just a `cc attr can make a world of difference.
I hope someone (preferably several someones) will find this useful. Questions, comments, suggestions and their ilk very welcome.

Click 

@@()
I kind of like where you're aiming. One of the things I'm working on is a mix-up of @@() comments. So the documentation exists within the attribute (preferably at the END of the code) in an @@() comment, but which can also be accessed for display. I don't have a working example of this, at present, because I'm elbow-deep in other stuff. But a pseudo-example would be something like:
&attr obj=[code(blah blah)][@@(!!Yada)]
If you want the documentation, you do after(get(obj/attr),!!), or something like that.
This, of course, leaves out consideration for attribute limits (e.g., Rhost is 3998 chars, much smaller than Penn), so it may not be effective in ALL cases.
add a function_comment ?
When I'm debugging softcode (um, mine) I mentally step through the functions. I think "this does this, this does that, this does this...." it's arduous.
I don't think there is a way to do properly commented mush code without a compiler, yes?
Here's how I do it:
&function_thing #123 blah blah
&function_thing_views #123 foo foo
&function_thing_comment #123 This horrible function was written to cause pain to the casual observer.
I personally use a function_comment to comment my code.
Re: function_comment
This is roughly what my system does, except with a few differences and advantages. Here's a few I can think of offhand:
There's two attrs for documentation. If you really just want to do the minimum amount of work, it takes maybe 30 seconds to punch in a `cc attr and you'll at least have some documentation on the function's input and output.
If you want to be more thorough, or have more time/energy later, you can also put up a `doc attr, which is much like your _comment attr, but with a bit of structure and a dash of markup added in.
As a result of the above, it also helps make sure all of the arguments to a function are mentioned, and reduces the need a bit to add in your own ansi() emphasis.
For the person reading the documentation, it's easy to get a quick overview of all the functions on the target object and how to call them, without having to output the full text of each, or to blindly call up all documentation without having to examine the object first.
Off-line documentation
Over the years I've been engaged in Pennmush softcoding I've looked into various schemes for documenting the code I've produced. The latest, and in my opinion at least, the best I've found so far is to write the code off-line, in human readable layout and with suitable comments - including a comment block for each function or command.
I use gEdit and have created a language syntax highlight file for that editor, so the code is not just in a readable format but also neatly color coded. I also have a python script integrated into the external tools feature of gEdit so a single cntrl-F10 keypress converts the human readable code into a format ready to be pasted into a Mush client.
With these tools my coding productivity has increased significantly. The code is readable, and potentially well commented. Where it isn't is down to me and not any limitation of the method. I'm working on adding named %qX variables as well but that's in early beta stage and not getting much effort as I've found I don't really need it. I can document what each %qX register refers to in the comments. If anyone would be interested in having copies of the language syntax files for gEdit and the python script I use, I'll be glad to upload them to our (Champions Mush) website so they are accessible.
(Ayesha@ChampionsMush)
ps. There's now a page on Champions MUSH website with these files and descriptions on using them. I'm hoping showing a link isn't breaking the terms and conditions for posting here. It's not spam, it's exactly what I have stated above. The URL: http://cm2051.dune.net/softcode/codetools.html