API docs?

[Clu]

Hello all!

I was curious if anyone has compiled or if the Dev's intend to compile an API document that details the various classes and their methods?

I think the main reason that I loathe scripting anything is due to having to hunt through the various script files to find something that approximates the functionality I'm trying to produce.

I think an API doc would go a long way in helping to lower the learning curve and get shard sysops and scripters coding faster and more efficiently.

Just as a suggestion, if this seems a daunting task, there is an application called Doxygen (www.doxygen.org ) that can make this process a lot less of a hassle.

Anyway, a friendly question and suggestion.

Thanks!

[Sep102]

There currently is a document that should be in your root\docs folder called overview.html. It doesn't provide any detail on any classes or methods, but it does list the classes and the prototypes for all of their methods.

[Clu]

Ah, gotcha! I'll take a look-see at that, thanks Sep!

I think a doc with more detail would be a very helpful thing but having had to do it myself, I can respect the initial "Eesh!" that doing it tends to produce.

[Clu]

Yeah - thats a pretty good document. It looks like it was built with something similar to Doxygen.

Good stuff!

[Sep102]

Good, had a feeling that was close to what you were looking for. If you feel that it needs more detail though, feel free to write a tutorial describing the methods on the forum. As long as it's written accurately, I doubt anyone would have any complaints with it, in fact many I bet would be overjoyed.

[David]

I doubt the Devs will provide a more detailed document until RunUO is firmly out of beta. At this point things are still subject to change, and the guys that know the details are all busy.

[Clu]

I can certainly understand that!

I think the docs that Sep pointed me to will do nicely indeed. There are just a few particulars that are causing me to pause a bit but there are lots of examples in the code already with those so it shouldn't take me too long to get up to speed.

[Phantom]

Originally Posted by Sep102

There currently is a document that should be in your root\docs folder called overview.html. It doesn't provide any detail on any classes or methods, but it does list the classes and the prototypes for all of their methods.

Yes it does

What do you call every single public and private method and variable name listed in each class?

I call that detailed

[Sep102]

I call it detailed and you call it detailed, but the second newb on the left who thinks there should be an explanation for InRange in it doesn't

[Phantom]

Originally Posted by Sep102

I call it detailed and you call it detailed, but the second newb on the left who thinks there should be an explanation for InRange in it doesn't

True dat

Go see Team America :-)

[Clu]

By detailed, maybe details would have been a better descriptor.

The Class lists and method details are a great tool and for the most part thats enough, but there are a few ambiguous methods where to learn what the function does, you'd have to go through the code and interpret.

By in large the naming conventions are pretty straightforward and what functions do is fairly obvious, but its those rare exceptions where you have a really nice function that would do exactly the job you need it to but its named in a way that is not suggestive of its duty...

Anyway, beating a dead horse here. Maybe something to look for future releases but not really a high priority item.

[Phantom]

Of course if people really its needed, they could do it themselfs

[Clu]

Having someone outside of the team who wrote the code can produce docs that are inaccurate or leave out particulars that a developer be aware of - particularly in areas where the function of one piece of code has dependancies on another piece that are not readily obvious.

[Phantom]

Originally Posted by Clu

Having someone outside of the team who wrote the code can produce docs that are inaccurate or leave out particulars that a developer be aware of - particularly in areas where the function of one piece of code has dependancies on another piece that are not readily obvious.

Horrible excuse

At least I admit that I am to busy, or I would do it myself.

[Clu]

oh-kay..