in reply to Comment blocks & private methods

There are several solutions for multiline comments like turning a section of code into a string with q or HEREDOC, POD, or source filters if (0). The first category will trigger a warning in most cases (You could always start all your comments with 'igor' or 'dilbert' though :P). The second puts unused code in what should be useful documentation. The third uses source filters, which are impopular among several perl users (mostly because can cause confusing errors, since the code compiled by perl is not the one in the text file). The if (0) solution doesn't work on everything (if there's a BEGIN block somewhere in the commented code, it will still be executed), and won't compile if there's a syntax error in the disabled code.

To me the best solution still is source filters, but since most editors allow you to easily comment several lines of code at once, I just go for that (ctrl+Q on selected code on my version of notepad++, or other shortcuts depending on exactly what you want to do).

Edit: and for private methods, well LanX actually gave you the answer.

Replies are listed 'Best First'.
Re^2: Comment blocks & private methods
by LanX (Saint) on Dec 12, 2014 at 16:15 UTC
    > To me the best solution still is source filters

    Actually I agree here, cause I can't possibly see a problem in this case, since comments ARE sourcefilters! :)

    Sourcefilters arent bad by definition, it depends on the use case, and this one is legit!

    Cheers Rolf

    (addicted to the Perl Programming Language and ☆☆☆☆ :)

    update

    I have to revoke my opinion, source filters can't distiguish between multi line strings and code.

    But pod doesn't have this problem:

    $string = " bla =for doc a source filter would delete this part from the string =cut bla ";

      Except to parse comments correctly you have to parse perl, because knowing where a string (or string-like anything) starts and ends is really complicated (there are so many ways to start a string in perl that can be nested into each other that you have to parse the whole file correctly to be sure wether one part is code or a string), you wouldn't want your parser to change: "You can also use C-like comments: /* */" into "You can also use C-like comments: " or /\/*\*// # yup, good coding style into /\/ # that works just fine.

      I didn't have that point in mind when I wrote my comment though.

      Edit: in the end yes, POD may actually be the best idea. My bad :D

        > I didn't have that point in mind when I wrote my comment though.

        yeah see my update, (coevolution of better ideas! ;)

        > Edit: in the end yes, POD may actually be the best idea. My bad :D

        maybe a good feature request to to make empty =for without FORMAT and surrounding blank lines official for multi-line comments

        print "start - "; =for bla bla =cut print "stop!";

        My perl-parser as well as perldoc ignore those lines. Only emacs' cperl-mode insist on surrounding blank lines.

        Cheers Rolf

        (addicted to the Perl Programming Language and ☆☆☆☆ :)