what do you mean "=head1 SEE ALSO"?
Main Topics
Browse All TopicsWhat is the recommened/common pod format/template in practice? Of course, they will vary, but in general?
I have an example:
=pod
=head1 NAME
Debugging mod_perl Perl Internals
=head1 Description
This document explains how to debug Perl code under mod_perl.
=head1 Maintainers
Maintainer is the person(s) you should contact with updates,corrections and patches.
=over
=item *
Stas Bekman E<lt>stas (at) stason.orgE<gt>
=back
=head1 Authors
=over
=item *
Stas Bekman E<lt>stas (at) stason.orgE<gt>
=back
Only the major authors are listed above. For contributors see the
Changes file.
=cut
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
"=head1 SEE ALSO" can be used to point people to code that's similar to yours, or code that your code builds on. For example, if you extended a module called "Module::Foo", you'd put that module in the "=head1 SEE ALSO" section. Helps to give people some background.
POD is good for having multi-line comments too, similar to the /* */ structure in C. If you want to comment out an entire chunk of code, instead of putting a # before each line (which is tedious), you could put "=head1 COMMENT" at the beginning and "=cut" at the end.
There are also programs out there that'll transform POD into HTML or other formats for easy reading and dissemination.
POD and comment lines are sort of orthogonal. POD is supposed to be the external documentation for your code. It says what your code does. Comment lines are internal documentation. They say how your code does what it does. There's a difference there, really.
For example, you might have a method that takes two matrices and multiplies them. Your POD would say pretty much just that, "takes two matrices and multiplies them." Your comment lines would comment your code for the various steps along the way. I'd imagine comments such as "set up a loop to run along matrix A columns" or "initialize the output matrix". The external user doesn't need to know the nitty-gritty of how you multiply the matrices, only that you do so, but someone maintaining your code (you, perhaps, six months down the line) needs to know that nitty-gritty for debugging purposes.
Gurus, wonderful explanations. I googled but couldn’t find a good one showing examples for documenting classes, methods, attributes, arguments, inheritance, overload, etc. Documentation is always critical, and I’d like to have a decent example that can be “popularly” used in practice. Please recommend the examples for classes, methods, attributes, arguments, inheritance, overload, etc.
jl
The best way would be to copy the style of some authors who are especially good at it. Take a look at some of Damian Conway's modules to see his POD style; it's usually really good. You could definitely do worse than emulating his POD style.
Also, just go through CPAN (www.cpan.org) to see various other styles of POD.
I'd like to point out that you want to keep your documentation template as light as possible. Otherwise it won't be used anymore, because it contains too many sections that may not be relevant to every module. Using one that is pretty much standard on CPAN gives you just enough structure to be useful, but gives the documentor enough freedom to do what he likes. Remember that developers hate having to document; don't overburden them.
Business Accounts
Answer for Membership
by: kanduraPosted on 2005-11-01 at 10:04:54ID: 15202012
I generally use the format that Module::Starter gives you. That's roughly:
=head1 NAME
=head1 VERSION
=head1 SYNOPSIS
=head1 DESCRIPTION
=head1 FUNCTIONS or METHODS or EXPORTS
=head1 AUTHORS
=head1 BUGS
=head1 SEE ALSO
=head1 COPYRIGHT & LICENSE