tags:

views:

242

answers:

4

How do I comment a part of a single line in Perl, like the following line:

 if($clevel==0){#never happends}

I would like to be able to comment that last closing bracket, without going to a new line.

+3  A: 

The # sign starts a comment that ends with the end of the line.

lexu
yes i know, but i want to end the comment before the line ends.
Hermann Ingjaldsson
@Herrmann Ingjaldsson: there is no provision for that .. but look here for Perl6 ideas: http://dev.perl.org/perl6/rfc/102.html
lexu
oh well, question answered then.
Hermann Ingjaldsson
+3  A: 

A # and then a line break. You can treat them as a bracket of sorts, since little in Perl looses its meaning from being on different lines.

my $ans = 2 + rand( 5 ) + $pixels / FUDGE_FACTOR;

To

my $ans = # 2 + 
    rand( 5 ) + $pixels # / FUDGE_FACTOR
    ;

Or from:

if ( dont_know_how_this_breaks() && defined $attribute ) { 
   #...
}

To:

if ( # dont_know_how_this_breaks() && 
     defined $attribute ) { 
   #...
}
Axeman
Yeah that's true, but i ment to write something, then comment and then write again. All within the same line.
Hermann Ingjaldsson
@Hermann Why doesn't splitting the line of code as in this answer do what you want?
Greg Bacon
because it requires me to split the line.i want the sentence to continue right after the comment.a small explanation for a single word in a sentenceshouldn't require to break the line.the code im writing is the following:if($clevel==0) {#never happends}here it would be nice if i could finish that one closing bracket without going to the next line.its kinda like not needing to make a newline anytime one puts an [] into a quotation.requiring that newline operator can decrease readability and compactness.And at last, how do i force a newline into a comment here?
Hermann Ingjaldsson
@Hermann Ingjaldsson: Just commenting that something doesn't happen isn't as useful as doing something like *asserting* it never happens. I've had code hit never-happens lines, and it's useful to report that it's hit a condition you never thought possible.
Axeman
+3  A: 

If it's really that important, use source filtering.

# C_Style_Comments.pm
package C_Style_Comments;
use Filter::Simple;
FILTER {   s{/\* .* \*/}{}gmx    };
1;

$ perl -MC_Style_Comments -e 'print /* 5, No wait, I mean */ 3'
3
mobrule
+1 for source filters. The way you have it, it looks like you could even comment out parts of a comment or a string. Cool
Axeman
Source filters are evil. Suddenly you can't trust the code in front of your eyes, because some invisible magic elsewhere in the program might be altering it. It may be useful in development, but stay far far away from it in production code. IMHO.
Ether
Like many evil things, there's a time and a place for source filters (this question isn't necessarily one of those times). Always wear your safety goggles.
mobrule
@Ether - I uploaded `Acme::SafetyGoggles` to CPAN for you ;-)
mobrule
@mobrule: heh, that's an awesome module! But people who use Acme modules are assumed to know what they're getting themselves into... I was just targeting that advice to beginners. :)
Ether
+4  A: 

Any reason you can't write :

if($clevel==0){#never happends}

as :

if($clevel==0){} #never happens

There are some tricks you can do to hide messages, such as:

0 and 'some comment'

But you're just going to make it more confusing if someone else has to maintain your code in the future.

Working within the constraints of a language, rather than trying to force it to act like some language you're more familiar with often leads you to learn new things. I personally hate working in IDL, but some of the tricks for dealing with poor loop performance led me to optimize code I've since written in other languages.

Joe
For complete code maintainance, you shouldn't just comment on an "impossible condition", you should warn or die or print some amusing message (because that gets around) so that you *know* when the code has hit one of those "impossible" lines.
Axeman
@Axeman: I prefer to avoid 'die' after debugging some code where someone didn't consider how things might change in the future, thus hitting one of those 'this should never happen' sections. But you're right -- `warn 'this should never happen'` would accomplish the specific case that was asked.
Joe