Forum OpenACS Development: Documentation: let's find the old stuff and make it useful again

Hi.

I've noticed when looking at the API browser that functions I look up don't have any explanitory text in them. So, this was going to be a "Lets get going with docs writing!", and, indeed, I do want to do that. But I have found an important subtask that would be useful to be completed first in order to streamline the larger "Let's make sure everything is documented" effort.

Rather than contact anyone too early in the process, I decided to start on my own to write documentation for one file that's fairly close to the core (and that I was trying to understand at the time), then I switched to doing the TCL procs that themselves deal with documentation (since I'd have to learn about them in this process anyway).

Lo and behold, the docs are there! The problem is twofold:

  1. the docs that do exist in the TCL files of OACS's inner core are in TCL comments rather than being in doc strings which are part of ad_proc; and
  2. that documentation that exists there has evidently been ignored for many years. The listing shows item names (of parameters and even of the procs themselves) that are no longer the same as that they are there to document, among other phenomina.

The good news is there is a lot of documentation that is relevent and correct. Let's arrange to incorporate it:

I'm now on something of a crusade to move the docs from the # comments where they now exist to the doc string place in the ad_proc for each tcl proc. (why am I on this kick? because new developers can use the help.)

Due to (2) above, some of that documentation is relevent, and some not. The reason for this is apparently that while code changed, the docs were not changed and sorta stayed in the file attached by proximity to something it doesn't really refer to any longer.

So, my intent is to rewrite some of them, and just move others in with a FIXME tag which would appear to those who call up the procedure in the API browser.

I'd like to ask for some resources in this process; the most important of which would be other people who want to help with this process. The other is a folder somewhere in openacs file-storage where I can add files and folders.

I think this is a great idea, and it's relatively simple, as well. Just to be clear (I discussed this with Jim in IRC), he's recommending moving TCL comments which explain the procedure's overall functionality into the ad_proc comment section (where they should be!). TCL comments which document specific parts of the code will be left in place. I'm sure the rest of you understood it the first time 😊
Horray for Jim. We need more of that kind of documentation effort all over the toolkit.

In fact, we need to get our developers to understand the importance of documentation. Code _and_ document instead of "code, code, code. Documentation? What's that?"

Yes, this is good.  And Roberto, you're right, in my experience if people don't document code as they're writing it, they rarely find time to go back to do it.

I always try to write comments explaining tricky code as I'm writing it, otherwise I myself am likely to forget how it works.  For a complex proc like ad_form I didn't write the documentation in the header until I'd had some experience working with it as the design kept changes as I built real-live forms.  But I usually document the general functionality of a simpler proc as I'm writing it.

In another thread the subject of writing down coding conventions came up, starting with pre-existing aD stuff as a base.

Conventions for documenting should be part of this.

Jim ... do you need a folder or just commit rights to the relevant portions of the CVS tree?

As part of the effort to fix documentation, I have updated acs-tcl/tcl/defs-procs.tcl:
* Got rid of all the proc_doc's
* Moved comments that were outside or in function comments to within
  ad_proc documentation block.
* Added documentation where it was missing and I could figure out what 
  the function was supposed to do.
* Added explanation as to why the function was deprecated where I knew 
  the reasons.

I just saw Yon's message about the reasons for ad_parameter being deprecated, so I'll commit that now. I tested and everything is go.

OK, I been hacking away... and I came up with this report, which of course is just relevent to my own server (meaning that this info is only relevent to the files and packages installed on -my- server). I'll make the code available shortly, meanwhile you can see it on my musicy site :)

The Doc String Report

Here are some statistics I gathered that might suggest the volume of work involved...
<p>
I grabbed a copy of the acs-core module from cvs, on 2002-08-09 22:11utc, and I added my package and diff to it... On that date..
<p>
There are 303 ad_procs in a total of 42 files that have no doc string.
You can run this report too, here are the files:
<p>
<ul>
  <li>First, here's <a href="http://orie:9000/files/file?file_id=6556&show_all_versions_p=t">the diff</a> that makes ad_proc collect one more needed piece of information.
  <li>Finally, here's <a href="http://orie:9000/files/file?file_id=6554">the APM package</a> that produces and renders the report.
</ul>
<p>
Happy hunting.
Oops! Of course, you can't see that address... here are the corrected links:

  • First, here's the diff that makes ad_proc collect one more needed piece of information.
  • Finally, here's the APM package that produces and renders the report.

Happy hunting.

Alllllll righteyyyy thennnn...

OK, so Jim Carrey does that better than me :)

To date, I have joined or written the docs for approximately 175 ad_procs, most of those in acs-templating; this has been committed to the CVS.

PLEASE PLEASE TEST AND BANG ON THIS!

I believe I've been quite careful in the moving or creating of the doc strings, but I still want many many more eyes on the situation.

I know that a server with my doc string mods will start without error, or at least the error log formed from starting the server doesn't contain the string "error" in it, and things seem to work fine.

So again, Please look soon and often!