Looks good, but it would look a whole lot better with some
POD in there. Get rid of those ugly comments that explain
what each subroutine does and replace them with some sexy
POD. Personally, i prefer to put all POD at the end of the
script, but you can place each description of the
subroutines with the subroutines if that eases your burden
of documentation. (Me, i just use gvim and split the window
:D). Here is an example to get you started (hint,hint):
# The loop for ripping
do {
system("eject -t $device");
ripping($title, $device);
}while(! prompt4("Hit Enter to continue, or q to quit. "));
__END__
=head1 NAME
BookOnCD.pl - BooksOnCD to MP3
=head1 DATE
Most recently modified on ... (CVS could do this for you, BTW)
=head1 DESCRIPTION
This script will rip BooksOnCD to an MP3 format
that is readable by today's popular MP3 CD players.
=head1 SUBROUTINES
=over 4
=item B<prompt>
$boolean = prompt($scalar);
Verifies that the user typed some form of 'yes'
=item B<ripIt>
ripIt($directory,$device,$title,$disc,$tracks,$tracks);
This is the "Magic" function that rips the MP3's
from the CD and orders them.
=back
=head1 AUTHOR
atbitkin
=cut
Now, all you need do is type
perldoc BookOnCD.pl
and receive instant usage and API documentation. You can
also beef up your script easily with
POD::Usage
and one of the
Getopt modules if necessary.
By using the power of POD, you can use comments for what
they are really best for - comment what an otherwise
unintuitive piece of code is suppose to do - not turn your
program into a maintenance nightmare. Have fun! :)
Oh yeah ... you can find out more about POD via
perlpod.
jeffa
L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
