In .vimrc, you can add the following lines:
In other words, if your Leader is a backslash, you can type \pt to reformat the file using the .perltidyrc. If you are in visual mode (selecting lines with shift-v), then only the code you have currently have selected will be reformatted.
For emacs, you can use this snippet from Sam Tregar (<http://use.perl.org/~samtregar/journal/30185>):
TAP::Object is the common base class to all TAP::* modules, and should be for any that you write.
Exceptions should be raised with Carp:
Any documented sub that needs to be changed or removed (and would therefore cause a backwards-compat issue) must go through a deprecation cycle to give developers a chance to adjust:
1. Document the deprecation 2. Carp a suitable message 3. Release 4. Change the code 5. Release
The end-user and API documentation is all in the lib/ directory. In .pm files, the pod is inline to the code. See perlpod for more about pod.
For compatibilitys sake, we do not use the =head3 and =head4 commands.
=head1 SECTION Sections begin with an =head1 command and are all-caps.
NAME VERSION SYNOPSIS CONSTRUCTOR METHODS CLASS METHODS SOME OTHER SORT OF METHODS SEE ALSO
=head2 method The =head2 command documents a method. The name of the method should have no adornment (e.g. dont C<method> or C<method($list, $of, $params)>.)
These sections should begin with a short description of what the method does, followed by one or more examples of usage. If needed, elaborate on the subtleties of the parameters and context after (and/or between) the example(s).
=item parameter Use =item commands for method arguments and parameters (and etc.) In most html pod formatters, these do not get added to the table-of-contents at the top of the page.
L<Some::Module> Be careful of the wording of L<Some::Module>. Older pod formatters would render this as the Some::Module manpage, so it is best to either word your links as "(see <Some::Module> for details.) or use the explicit rendering form of <Some::Module|Some::Module>".
The version numbers are updated by Perl::Version.
The following formats are used with =begin/=end and =for commands for pod which is not part of the public end-user/API documentation.
note Use this if you are uncertain about a change to some pod or think it needs work.
=head2 some_method ... =for note This is either falsely documented or a bug -- see ...
developer =begin developer Long-winded explanation of why some code is the way it is or various other subtleties which might incite head-scratching and WTFing. =end developer deprecated =for deprecated removed in 0.09, kill by ~0.25
If you have commit access, please bear this in mind.
Development is done either on trunk or a branch, as appropriate:
If its something that might be controversial, break the build or take a long time (more than a couple of weeks) to complete then itd probably be appropriate to branch. Otherwise it can go in trunk.
If in doubt discuss it on the mailing list before you commit.
|perl v5.20.3||HACKING (3)||2015-04-17|