From: "Rainer Klute" <[EMAIL PROTECTED]>
> Andy:
>>Kind of the coding standard we agreed upon (off the top of my head) as a
>>group was:
>>
>>1. all public and protected functions must have javadoc
>>2. all subprojects must have at least a how-to and some sample code
>>explaining their basic use.
>>3. stuff must compile
>>4. the build must work
>
>+1
>
>I'd like classes and packages to have javadoc, too. This would give
>developers a broader view than the method docs' peephole view while
>still being more detailed than HOWTO and sample code. Does that
>sound reasonable? Perhaps we should *encourage* it, but not
>*require* it.
Good point. IMHO we should require class javadoc.
As for packages, they could be explained in the xdocs.
Since javadocs are sufficiend for code-use during work, I propose we try to
standardize xdocs for packages-subprojects.
Something like:
- scope: what it does
-reasoning
-alternatives
- structure: how classes and code in package are organized
-tree
-functional view
-rejected designs
- HOWTO: get it working
-hello world
-tutorial
-advanced features
-integration and distribution tips
- samples:
-basic
-med
-advanced
- future
-todo
-timeline
-future design architecture
-RFE
Each package shall contain a projectinfo.xprj file that contains:
-scope: what it does
-licence
- build howto
-basic demo howto
-changes
-todo
-timeline
-links to site
I'll integrate it in Krysalis Centipede, as always :-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
