Thanks to visit codestin.com
Credit goes to past.justatheory.com

Attention! You’re reading history

This is the past design for Just a Theory, and no longer updated. It's provided mainly for historical reasons. You probably want to read the current site.

JSDoc Doesn't Quite do the Trick for Me

After my request for JavaScript documentation standards, I investigated the one I found myself: JSDoc. I went ahead and used its syntax to document a JavaScript class I'd written, and it seemed to work pretty well. Initially, my main complaint was that their was no easy way to include arbitrary documentation. Everything has to be associated with a constructor, attribute, or method. Bleh.

But then I started documenting two purely functional JavaScript files I'd written. These just create functions in the Global scope for general use. And here's where JSDoc started to really become a PITA. First, functions with the same names in the two files were declared to be pre-declared! They two files are part of the same project, but users will generally use one or the other, not both. But JSDoc has taken it upon itself to refuse to document functions that are in two different files in the same project. Surely that's the JavaScript interpreter's responsibility!

The next issue I ran into (after I commented out the code in JSDoc.pm that refused to document functions with the same names) was that it didn't recognize one of the files as having documentation, because there was no constructor. Well duh! A purely functional implementation doesn't have a constructor! It seems that Java's bias for OO-only implementations has unduly influenced JSDoc, even though JavaScript applications often define no classes at all!

The clincher in my decision to ditch JSDoc, however, came when I realized that, for most projects, I won't want the documentation in the same file as the code. While I generally prefer that they be in the same file, I will often have 4-10 times more documentation than actual code, and the bandwidth overhead seems unnecessary. JavaDoc and JSDoc of course require that any documentation be in the same files, since that's where they parse method signatures and such.

So I think I'll follow Chris Dolan's advice from my original post and fall back on Good 'ole POD. POD allows me to write as much or as little documentation as I like, with methods and functions documented in an order that makes sense to me, with headings even! I can write long descriptions, synopses, and even documentation completely unrelated to specifics of the interface. And all in a separate file, even!

This will do until someone formalizes a standard for JavaScript. Maybe it'll be KwiD?

Backtalk

Marcus Ramberg wrote:

docs in templates?

I've been considering serving javascript as Template Toolkit Templates, and putting the POD directly into the javascript as TT [%# #%] blocks. That way, I can keep the documentation in the template file and not worry about the bandwidth issues. This works welll with mason templates as well, with <%doc> blocks. I suppose this would work with KWID as well, but as it doesn't have any documentation yet, I'm not sure.

John Sequeira wrote:

David, You might want to check out LEO and it's implementation of literate programming sometime. It solves the problem of embedded documentation in a general way and solves a number of other source code issues as well (It really helps tame tt2/xslt/etc files that don't have inherent structure). It has a learning curve, but it's worth it.

John wrote:

Oh -- I should give you the URL: http://leo.sf.net

Theory wrote:

re: docs in templates?

Marcus,

The only problem with using TT or Mason or HTML::Template or Embperl, or JSP or whatever to serve JavaScript is that you're adding the overhead of the templating architecture to every request for what should essentially be a static document. Seems silly to me when one can just use separate files.

But its worth doing if it needs to go into a template, anyway. Thanks for the suggestion.

—Theory

Marcus Ramberg wrote:

re: docs in templates?

Theory, that's true, but you can easily set up a build process with TT that processes the javascript and strips the pod before installation. it can also generate .pod files first...

Theory wrote:

re: docs in templates?

Marcus

Well then I might as well just use Pod::Simple, eh?

—Theory