http://www.perlmonks.org?node_id=455980

gopalr has asked for the wisdom of the Perl Monks concerning the following question:

Dear Monks,

We are using comment a line by #(hash).

How to comment more than one line.

Replies are listed 'Best First'.
Re: More than One Line Comment
by salva (Canon) on May 11, 2005 at 13:42 UTC
    pod is your friend:
    =for comment multiline comment goes here =cut
    and anyway, you can make multiline comments placing monoline ones contiguosly... that is the most common way of doing it!
    # multiline # comment # goes # here
    any good editor will let you comment/uncomment full blocks with a few key strokes if that is the problem
Re: More than One Line Comment
by sweetblood (Prior) on May 11, 2005 at 13:42 UTC
    I use POD tags:
    =comment some relevant comment about the comment block whatever ... =cut
    I do the same for commenting out blocks of code while debugging.

    HTH

    Sweetblood

Re: More than One Line Comment
by Fletch (Bishop) on May 11, 2005 at 13:35 UTC

    Just put hashes in front of each line (personally I use ## as it makes things stand out a bit more, but that's just me). Or see perldoc perlpod.

      Use Pod comments ==pod All the lines under this will not get executed ==cut

        Erm, ITYM =pod and =cut (as perldoc perlpod that I referred to above would explain . . . ). And <code> tags might help your example.

Re: More than One Line Comment
by arc_of_descent (Hermit) on May 11, 2005 at 13:31 UTC

    If you really need it, then have a look at Acme::Comment. Personally though, I use single line comments. It helps me comment less on the code. :-)

Re: More than One Line Comment
by tomhukins (Curate) on May 11, 2005 at 13:46 UTC
    You can use Pod as follows:
    =begin comment This comment will neither show up in the Pod nor in the code. Hooray! =end comment =cut
Re: More than One Line Comment
by ww (Archbishop) on May 11, 2005 at 13:40 UTC
    See also the way pod works
    if ( foo < 0 ) {...
    =HEAD multi line comment here =cut
    x++;
    }
    etc
    update strikes added in deference (and with a wink) to cog's premature deprecation of perl 7 useage....
    and, noted (with awe!) the number of similar replys which appeared almost simultaneously
    <:<})
      Considering that  foo < 0 returns false (it's the bareword foo), even if it wasn't pod but it was syntactically correct, it would still work O:-)
Re: More than One Line Comment
by BrowserUk (Patriarch) on May 11, 2005 at 14:13 UTC

    Wouldn't it be nice if the sequence '#{\n' caused the block that begins with the open brace became a nop. So quick and simple to comment out/uncomment an if clause, or the body of a for loop, or an entire subroutine:

    ... if( .. ) #{ ... } ... while( ... ) #{ ... }

    Literally, a block comment :)


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

      It might be easy, but it is also very subtle and not very noticable. I guess a good syntax highlighter could solve that, but it looks like something that would be easy to overlook while debugging.

      I comment out blocks very quickly using my editor. In Vim I just cursor to the { or the }, then hit Shift-V % .c and the entire block is commented. To uncomment, use the same procedure except use .C instead of .c.

      The .c command is provided by the BlockComment plugin found here. The Shift-V starts line by line highlighting and the % finds the matching bracket to the one you are currently on or near. You could probably write a simple macro that does the same thing in one or two keypresses as well.

      - Cees

        Needless to say, but I don't use vim or emacs. My editor can do that too, but it's not the point.

        The subtlety of this is that it comments/uncomments a block. A block as defined by the language.

        Not some manually chosen grouping of an artificial concept of 'lines';

        Your point that it could be overlooked is valid, but if a block is going to be commented out (semi-)permenantly, then I would either put it into a pod comment, or physically remove it. The use of being able to comment out a block in a block-strucured language would be to test it's effect in the short term. A quick "what if" check whilst debugging. Easy to do and undo.

        If, having tried the idea out, you decided to make it semi-permenant, then you could go back and use a macro to make it more distinctive.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.
      If you can identify the beginning of the block yourself (and the opening brace is at the end of the line, as you stipulate), you can stick 0 and do { # in front of it and get the block commented out. It doesn't let you get away with syntax errors in it, but I would think that a block would have to be properly formed for block comments to work, anyway.
      ... 0 and do { #if (whatever) { ... } ... 0 and do { #while (whatever) { ... }

      Caution: Contents may have been coded under pressure.
      if( 0 and ... ) { ... } ... while( 0 and ... ) { ... }

        That's pretty good, but has the effect of also disabling any side effects of the conditional. Sometimes that's okay, but mostly you want the rest of the code to run normally and only disable the action within the block.

        It also misses the all the other opportunities where the #{ ... } might work, from bareblocks to inline blocks to subroutine bodies. In fact anywhere where a scoping block can currently exist, if that block is preceded by a #, then the entire block would be made noop.

        It even looks (to the non-expert source diver I am) as if it would be fairly easy to implement. There are some edge cases that would need to be dealt with if it were to be truely universal. For example, to work with the inline blocks of map and grep, it would need to replace the disabled block with a default behaviour. Eg. pass everything through for grep, and the input unchanged for map.

        Dealing with non-core and user-defined map-like subs, (List::Util::reduce/first, etc), would be a problem, but then they need prototypes to function and there are a lot of dark corners surrounding protoyped subs; one more probably wouldn't hurt.

        Any way you cut it, the absence of a proper multi-line comment is a thorn in the side of Perl 5 that I'd love to see corrected in Perl 6. I think the addition of a scoped-comment, one that works with the language structure rather than arbitrary lines, would be a unique and powerful feature of the new language.

        The only good argument against it I've seen is the "not very obvious/visible", which as I outlined it above is very valid. However, I see no reason why the syntax shoudn't be extended to be "an open brace preceded by 1 or more #s with no intervening whitespace or other characters. That would allow for people who favour delimiting their comments in very obvious ways to do something like

        if( ... ) ###################################################################### +######{ ... } ## or while( ... ) ########{ ... ... }

        As programmers, our eyes are already tuned to pairing braces, and with proper indentation, it is fairly intuative to see the extent of the block(-comment).


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
Re: More than One Line Comment
by mrpeabody (Friar) on May 12, 2005 at 02:27 UTC
    perldoc -q comment

    Learn to use the help system.

Re: More than One Line Comment
by tphyahoo (Vicar) on May 13, 2005 at 07:58 UTC
    I use a text editor with regex find and replace. To comment, I highlight the lines I want and replace

    ^

    with

    #

    Then to uncomment I replace

    ^#

    with nothing.

Re: More than One Line Comment
by tphyahoo (Vicar) on Nov 17, 2005 at 11:24 UTC
    A gotcha that got me for pod style comments such as
    =for comment blah =cut
    The =for and =cut MUST GO AT THE BEGINNING OF THE LINE.

    YOU CANNOT INDENT THEM.

    The lack of sand multi-line commenting (sane = something like most other languages have) is one of my major pet peeves with perl. Personally I usually just use #. I am thinking of trying out Roy Johnson's idea of 0 and do type comments. And... I don't like pod-style comments, largely because they're unindentable and mess up my pretty use of whitespace. Yuck.

      I'd say "can't indent them" is a feature.

      Be definition, we are talking about cases of multiline comments, and such a chunk deserves easily identifiable start/stop markers. On their own lines. And of course everything between the markers gets to stay exactly where it was before you marked it off. Later, if you decide that you can live with those lines running after all (as below), you can put '#' comments in front of your pod markers; don't delete your pod markers because you may change your mind yet again and desire to re-ignore those lines.

      #=pod #no warnings 'all'; # doesn't seem to prevent error message +s.... my $xform = new RTF::TEXT::Converter->new( output => \$output_string ); $xform->parse_string( $input_string ); #=cut
      But a "good style" rule somewhere says "Don't abuse pod this way!" Well, I don't put my user documentation for the program within the file, I put it in it's own separate pod file, and so the two usages never get mixed up.

      I also use the 'if 0' approach to isolate code blocks that I don't want to run. Particularly for code blocks that help me with debugging. By formatting them as follows, i.e. with 'if 1' starting in column 1 when I want a debugging section to fire, I can find those sections easily via vim with '/^if 1' and turn them off by editing to 'if 0'. While I could also use a "$debug" flag, I'd then have to wade through all the other debugging output from the other 'if $debug' sections when I really only want the surgical strike of enabling this particular block. The problem with using 'if 0' to comment out questionable/narrative sections of stuff is that the compiler complains about improper innards even though you don't want any of it to run.

      do { # Should be unnecessary to see this; the data is in the dd_config_ +info file my $msg = Dumper( \%ddcon_contents, \@ddcon_order, $dd_con_defaults, ); esdw "ddc_data2 $msg\n"; } if 1;