[R] [FORGED] Re: Block comment?

Duncan Murdoch murdoch.duncan at gmail.com
Sun Sep 3 14:43:26 CEST 2017


On 03/09/2017 12:49 AM, Rolf Turner wrote:
> 
> On 03/09/17 12:29, Duncan Murdoch wrote:
> 
>> On 02/09/2017 6:57 PM, Rolf Turner wrote:
>>> On 03/09/17 03:56, William Dunlap via R-help wrote:
>>>> Is the reason you want a block comment containing code (as opposed to
>>>> arbitrary text) that you want to be able to easily run the commented out
>>>> code?  If so the 'if()' construct has the advantage that you only
>>>> need to
>>>> change code at the start of the comment, not at both ends.
>>>>
>>>> The if(FALSE) could be if(isTRUE(getOption("DEBUG_ISSUE_XYZ"))) so you
>>>> would not even have to change code to re-enable the debugging code, just
>>>> call options(DEBUG_ISSUE_XYX=TRUE)).
>>>
>>>
>>> (a) The foregoing is getting too subtle for my feeble brain.
>>>
>>> (b) A fundamental problem with the
>>>
>>>       if(FALSE) {
>>>          ...
>>>       }
>>>
>>> paradigm is that the enclosed code must be syntactically valid, and
>>> there are certainly situations in which one might wish to comment out
>>> sections of code that are *not* syntactically valid.  E.g. one might
>>> wish to comment out *part* of a piece of syntactically valid code for
>>> the purpose of experimenting with an alternative approach.
>>
>> If the code is not syntactically valid, why would you expect the block
>> comment to be syntactically valid?
> 
> I thought I had made that clear.  One might wish to comment out a
> *piece* of syntactically valid code (with a view to replacing it).
> The piece commented out might not be syntactically valid simply because
> it is *just a piece* and might thereby be incomplete.
> 
>> The proposal at the start of this
>> thread was that #{ would open the block and would be matched by }# to
>> close the block.  What if the closing sequence occurred within the block
>> unintentionally?  Then the poor feeble programmer would be even more
>> confused.
> 
> Do not the same considerations essentially apply to the well established
> /* .... */ convention used in C?  Well maybe you simply *can't* get the
> "*/" string within a block of C code, but still ....

Those aren't nestable.  You can have as many opening /* sequences as you 
like, and the first */ will close the comment.  The usual recommendation 
for nestable comments in C++ is to use #if 0 ... #endif, a lot like 
Uwe's suggestion.  (Since this is a preprocessor command, what falls 
between the markers doesn't need to be legal C++, but it does need to be 
legal preprocessor markup.)

> 
> If "#{....}#" runs this risk, then some other construction which doesn't
> run the risk could be used.
> 
>> I like the current rule:
> 
> De gustibus non disputandum.
> 
>> any line starting with # is a comment.
>> (Actually the rule is a bit more subtle than that, but it's close.)
>> If I want to comment out a block, I can spend a long time typing # at
>> the start of every line, or I can ask my editor to do it.  I don't need
>> to worry if something in the block unintentionally closes it, because
>> that's impossible.  If the first line is a comment, all the rest are too.
> 
> I don't follow the foregoing, but no matter.  I'm slow.

A shorter version:  just put # at the start of every line in the block.
That's nestable, but if you mess up the nesting, it's still completely 
obvious what is commented out and what is not.

Duncan Murdoch

> 
> This issue is quite obviously No Big Deal.  Block comments are a
> convenience that it would be nice to have, but obviously one can live
> without them and not suffer unduly.
> 
> cheers,
> 
> Rolf
>



More information about the R-help mailing list