Re: Are there any drawbacks to comments -- can they hurt the performance of Perl code?

This is straight from the chapter on Documentation in Perl Best Practices by Damian Conway: "..place you comments at the end of the file, preferably after the __END__ marker so that the compiler does not have to look at it at all." It can't get better than that, I guess.

Comment on Re: Are there any drawbacks to comments -- can they hurt the performance of Perl code?

Replies are listed 'Best First'.
Re^2: Are there any drawbacks to comments -- can they hurt the performance of Perl code? by imp (Priest) on Aug 15, 2006 at 12:47 UTC
Actually that section was discussing POD, and this thread is discussing inline comments. I agree with moving POD to the __END__ block. `# What this function does sub foo { #Something worth noting blah(); } __END__ ... =head2 foo() my $result = foo(1,2);` [download] The section of Best Practices that was mentioned is as follows: Having decided to keep the documentation together, the obvious question is whether to place it at the start or the end of the file. There seems to be no particular reason to place it at the beginning. Anyone who is looking at the source is presumably most interested in the code itself, and will appreciate seeing it immediately when they open the file, rather than having to wade though several hundred lines of user documentation first. Moreover, the compiler is able to do a slightly more efficient job it if doesn't have to skip POD sections before it finds any code to compile. So place your POD at the end of the file, preferably after the _ _END_ _ marker so that the compiler doesn't have to look at it at all. Or, if you're using a _ _DATA_ _ section in your implementation, wrap the documentation in =pod/=cut directives and place it just before the _ _DATA_ _ marker.	[reply] [d/l]

Replies are listed 'Best First'.

Re^2: Are there any drawbacks to comments -- can they hurt the performance of Perl code?
by imp (Priest) on Aug 15, 2006 at 12:47 UTC

# What this function does
sub foo {
    #Something worth noting
    blah();
}

__END__

...

=head2 foo()

  my $result = foo(1,2);
[download]

Best Practices

Having decided to keep the documentation together, the obvious question is whether to place it at the start or the end of the file.
There seems to be no particular reason to place it at the beginning. Anyone who is looking at the source is presumably most interested in the code itself, and will appreciate seeing it immediately when they open the file, rather than having to wade though several hundred lines of user documentation first. Moreover, the compiler is able to do a slightly more efficient job it if doesn't have to skip POD sections before it finds any code to compile.

So place your POD at the end of the file, preferably after the _ _END_ _ marker so that the compiler doesn't have to look at it at all. Or, if you're using a _ _DATA_ _ section in your implementation, wrap the documentation in =pod/=cut directives and place it just before the _ _DATA_ _ marker.

[reply]
[d/l]