in reply to Guidelines for listing functions/methods in POD?

G'day Dallaylaen,

These are just my thoughts and personal preferences on the subject. I don't even present these as recommended guidelines. It's entirely your choice whether you wish to implement any of these ideas.

I do like to see function names in the index because it aids page navigation. I only want to see the function name appearing once in the index; not multiple entries with every variation of the argument list.

I prefer to add function names alphabetically; again, for ease of navigation. I would normally add a function name at the =head2 level. With a large number of functions which, perhaps, fall into some natural grouping, I might use =head2 for group names and =head3 for the function names. Whether or not I decide groupings are needed, I'll generally aim for all functions to be at the same =headN level.

Here's how I might present a function with a variable argument list:

=head2 function C<function> can take various arguments as follows. $retval = function(); $retval = function($arg); $retval = function($arg, \%arg_map); $retval = function($arg, \%arg_map, \@arg_list); The arguments are: =over 4 =item C<$arg> A string denoting ... The default is ... =item C<%arg_map> This is a hash of ... ... =back Missing arguments use the defaults shown. The return value (C<$retval>) is always ...

Obviously, that's just a very sketchy outline. Meaningful names for variables, even in documentation, greatly aid comprehension. And, of course, when I come back to this in six months, there should be sufficient information for me to use function(...) without having to search through the source code: if it doesn't do that for me, it won't do it for others, and I've just wasted my time bothering to pretend to provide documentation.

— Ken