# from Ian Malpass # on Wednesday 06 June 2007 08:08 am: > * Has copyright details > * Has license details
On bigger projects, these things sometimes get done as "see the main module documentation for copyright and license statement". Thus, it would be good for this to be configurable as something like "has block $x", where $x is specified in a "pod_blocks/$x" file in the project tree. Similarly, I would like overrides to be able to be specified without comments or other markers in the code. Maybe a yaml file of module/method settings. (I'm imagining that I'll one day be reading a file with critic+pod_coverage+pod_critic+tidy markup in it and my eyes will bleed dry.) > * Method docs have examples > * No spelling errors (borrowing Pod::Spell) What David said. Also consider the various styles of method documenting. I don't like the '=item method', but it happens. I really don't like '=item method(parameters)', but again. There better be some way to per-project declare this policy because anything besides "=head2 method\n" is an error in my codebase. The spelling thing could maybe be helped via C<method>. Would be nice to know that you didn't accidentally type some_metod_name when you wanted some_method_name. Possibly use C<Other::Module::method> to quality external refs. Of course, "http://example.com";, acronyms, "Ingy" and similar items imply that a high-quality and sufficiently-hookable spellchecker are needed. AFAIK, that doesn't exist. > * Module names are links See 'See the "L<perlpod> documentation." may become "See the the perlpod manpage documentation."' Too many links don't do that correctly already. Thus, requiring links might be just making more trouble. --Eric -- Consumers want choice, consumers want openness. --Rob Glaser --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------
